<?xml version="1.0" encoding="utf-8"?>
<vulnerabilities xmlns="http://tempuri.org/XMLSchemaOptions.xsd">

<vuln_items>wasc_1</vuln_items>
<vuln_item_wasc_1>
	<alert>Brak uwierzytelnienia</alert>
	<desc>Niewystarczające uwierzytelnianie występuje, gdy witryna sieci web pozwala atakującemu na dostęp do poufnej zawartości lub funkcji bez konieczności właściwego uwierzytelnienia. Narzędzia administracyjne oparte na sieci Web są dobrym przykładem witryn internetowych zapewniających dostęp do poufnych funkcjonalności. W zależności od konkretnego zasobu online, te aplikacje internetowe nie powinny być bezpośrednio dostępne, bez konieczności poprawnego weryfikowania tożsamości.

Aby obejść konfigurowanie uwierzytelniania, niektóre zasoby są chronione przez "ukrywanie" określonej lokalizacji i nie łączenie lokalizacji z główną witryną internetową lub innymi miejscami publicznymi. Jednak takie podejście to nic innego jak "Bezpieczeństwo Przez Zaciemnienie". Ważne jest, aby zrozumieć, że nawet jeśli zasób jest nieznany atakującemu, nadal jest dostępny bezpośrednio za pomocą określonego adresu URL. Konkretny adres URL może zostać wykryty za pomocą sondowania Brute Force dla typowych lokalizacji plików i katalogów (na przykład / admin), komunikatów o błędach, dzienników stron odsyłających lub dokumentacji, takich jak pliki pomocy. Zasoby te, niezależnie od tego, czy są oparte na treści, czy funkcjonalności, powinny być odpowiednio chronione.</desc>
	<solution>Faza: Architektura i Projektowanie
Użyj uwierzytelnionego framework lub biblioteki, takich jak funkcja uwierzytelnienia OWASP ESAPI.</solution>
	<reference>http://projects.webappsec.org/Insufficient-Authentication</reference>
	<reference>http://cwe.mitre.org/data/definitions/287.html</reference>
	<reference>http://cwe.mitre.org/data/definitions/284.html</reference>
</vuln_item_wasc_1>

<vuln_items>wasc_2</vuln_items>
<vuln_item_wasc_2>
	<alert>Niewystarczające Uprawnienia</alert>
	<desc>Niewystarczające wyniki uprawnień, podczas kiedy aplikacja nie wykonuje odpowiedniej kontroli by zapewnić, że użytkownik przeprowadza funkcje lub uzyskuje dostęp do danych w sposób zgodny z polityką bezpieczeństwa. Procedury autoryzacji powinny wyegzekwować co może zrobić użytkownik, usługa lub aplikacja. Kiedy użytkownik jest uwierzytelniony na stronie internetowej, nie musi oznaczać to, że użytkownik powinien dostać pełny dostęp do całej zawartości i funkcjonalności.

Niewystarczająca Autoryzacja Funkcji

Wiele aplikacji zapewnia różną funkcjonalność różnym użytkownikom. Witryna z wiadomościami pozwala użytkownikom przeglądać wiadomości, ale nie je publikować. System księgowości będzie miał inne uprawnienia dla urzędnika odpowiedzialnego za rozliczanie kosztów i urzędnika odpowiedzialnego za przychody finansowe. Niewystarczająca autoryzacja funkcji ma miejsce, gdy aplikacja nie umożliwia użytkownikom dostępu funkcji aplikacji z naruszeniem polityki bezpieczeństwa.

Bardzo wyraźnym przykładem było hak procesu aplikacyjnego w roku 2005 w Szkole Przedsiębiorczości w Harvardzie. Błąd autoryzacji umożliwia użytkownikom przeglądanie własnych danych kiedy nie powinni uzyskać dostępu do tej części witryny internetowej.
 
Niewystarczająca Autoryzacja Funkcji

Wiele aplikacji ujawnia podstawowe identyfikatory danych w adresie URL. Na przykład podczas uzyskiwania dostępu do dokumentacji medycznej w systemie można mieć adres URL, taki jak:

http://example.com/RecordView?id=12345

Jeśli aplikacja nie sprawdziła poprawnie odczytu uwierzytelnionego identyfikatora użytkownika, wtedy może wyświetlać użytkownikowi dane, których nie powinien widzieć.

Niewystarczająca Autoryzacja Danych jest bardziej powszechna niż Niewystarczająca Autoryzacja Funkcji, ponieważ programiści zwykle mają pełną wiedzę o funkcjonalności aplikacji, ale nie zawsze mają pełne odwzorowanie wszystkich danych, do których aplikacja będzie mieć dostęp. Programiści często mają ścisłą kontrolę nad mechanizmami autoryzacji funkcji, ale polegają na innych systemach, takich jak bazy danych, w celu autoryzacji danych.</desc>
	<solution>Fazy: Architektura i Projektowanie; Obsługa
Bardzo starannie zarządzaj ustawieniami, zarządzaniem i obsługą uprawnień. Jawnie zarządzaj strefami zaufania w oprogramowaniu.

Faza: Architektura i Projektowanie
Upewnij się, że odpowiednie kategoryzowanie jest wbudowana w konstrukcję systemu i że kategoryzowanie służy do umożliwienia i dalszego wzmocnienia funkcji oddzielania uprawnień. Architekci i projektanci powinni opierać się na zasadzie najmniejszego przywileju, aby zdecydować, kiedy należy użyć i zrzucić przywileje systemowe.</solution>
	<reference>http://projects.webappsec.org/Insufficient-Authorization</reference>
	<reference>http://cwe.mitre.org/data/definitions/284.html</reference>
	<reference>http://cwe.mitre.org/data/definitions/285.html</reference>
</vuln_item_wasc_2>

<vuln_items>wasc_3</vuln_items>
<vuln_item_wasc_3>
	<alert>Przekroczenie zakresu liczb całkowitych</alert>
	<desc>Przekroczenie zakresu liczb całkowitych to stan, który występuje, gdy wynik operacji arytmetycznej, takiej jak mnożenie lub dodawanie, przekracza maksymalną wielkość typu liczby całkowitej używanej do jej zapisania. Gdy wystąpi przekroczenie zakresu liczb całkowitych, interpretowana wartość będzie wyglądać tak, jakby zawierała "owiniętą wokół" wartość maksymalną i rozpoczęła się ponownie od wartości minimalnej, podobnie do zegara, który pokazuje 13:00, wskazując na godzinę 1:00.

Na przykład ośmiobitowa liczba całkowita ze znakiem na najpopularniejszych architekturach komputerów ma maksymalną wartość 127 i wartość minimalną równą -128. Jeśli programista zapisze wartość 127 w takiej zmiennej i doda 1 to wynik powinien wynosić 128. Jednak ta wartość przekracza maksimum dla tego typu liczby całkowitej, więc zinterpretowana wartość "zawija się" i staje się -128.</desc>
	<solution>Faza: Wymagania
Upewnij się, że wszystkie protokoły są ściśle zdefiniowane tak, że wszystkie zachowania poza granicami można łatwo zidentyfikować i wymagają ścisłej zgodności z protokołem.

Faza: Wymagania
Używaj języka, który nie zezwala na wystąpienie tego osłabienia lub zapewnia konstrukcje, które ułatwiają uniknięcie tego osłabienia.
Jeśli możliwe, wybierz język lub kompilator, który wykonuje automatyczne sprawdzanie granic.

Faza: Architektura i Projektowanie
Używaj sprawdzonej biblioteki lub struktury, które nie pozwalają na wystąpienie tego osłabienia lub wprowadzają konstrukcje, które sprawiają, że to osłabienie jest łatwiejsze do uniknięcia.
Korzystaj z bibliotek lub struktur, które ułatwiają obsługę liczb bez nieprzewidzianych konsekwencji.
Przykłady obejmują bezpieczne pakiety obsługi liczb całkowitych, takie jak SafeInt (C ++) lub IntegerLib (C lub C ++).

Faza: Implementacja
Wykonaj sprawdzenie danych wejściowych w dowolnej postaci numerycznej upewniając się, że znajdują się w oczekiwanym zakresie. Wymuś, aby dane wejściowe spełniały zarówno minimalne, jak i maksymalne wymagania dotyczące oczekiwanego zakresu.
Jeśli możliwe, używaj liczb całkowitych bez znaku. Ułatwia to zrealizować sprawdzanie poprawności dla przekroczenia zakresu liczb całkowitych. Jeśli musisz użyć liczb całkowitych ze znakiem, upewnij się, że twój zakres wyboru zawiera zarówno minimalne jak i maksymalne wartości.

Faza: Implementacja
Zapoznaj się z podstawową reprezentacją języka programowania i jego interakcją z obliczeniami numerycznymi (CWE-681). Zwróć szczególną uwagę na rozbieżności w rozmiarach bajtów, precyzję, wyróżnienia ze znakiem/bez znaku ścięcie, konwersję i rzutowanie między typami, obliczenia "nie-liczby" oraz sposób, w jaki twój język obsługuje liczby, które są zbyt duże lub zbyt małe, aby zapewnić ich przedstawienie.
Uważaj także na konta 32-bitowe, 64-bitowe i inne potencjalne różnice, które mogą wpłynąć na numeryczne przedstawienie.

Faza: Implementacja
Sprawdź dokładnie ostrzeżenia kompilatora i wyeliminuj potencjalne krytyczne problemy zabezpieczeń, takie jak niezgodność Oznaczonych/Nieoznaczonych. Nawet jeśli słabość jest rzadko wykorzystywana, pojedyncza awaria może doprowadzić do narażenia całego systemu.</solution>
	<reference>http://projects.webappsec.org/Integer-Overflows</reference>
	<reference>http://cwe.mitre.org/data/definitions/190.html</reference>
</vuln_item_wasc_3>

<vuln_items>wasc_4</vuln_items>
<vuln_item_wasc_4>
	<alert>Niewystarczająca Ochrona Warstwy Transportowej</alert>
	<desc>Niewystarczająca Ochrona Warstwy Transportowej
Niewystarczająca ochrona warstwy transportowej umożliwia komunikację z niezaufanymi stronami trzecimi, gwarantując atak w celu złamania zabezpieczeń aplikacji sieciowej i / lub kradzieży poufnych informacji. Strony internetowe zazwyczaj używają Bezpiecznej Warstwy Gniazd Transportowych/ Ochrony Warstwy Transportowej (SSL/TLS), aby zapewnić szyfrowanie w warstwie transportu. Jednakże dopóki strona internetowa nie jest skonfigurowana do używania SSL/TLS i skonfigurowana poprawnie do używania SSL/TLS, to strona może być podatna na przechwytywanie ruchu internetowego lub na modyfikacje.
 
Brak Szyfrowania Warstwy Transportowej
Kiedy warstwa transportowa nie jest zaszyfrowana, cała komunikacja pomiędzy stroną internetową a klientem jest wysyłana w formacie zwykłego tekstu, co otwiera możliwość przechwycenia, wstrzyknięcia i przekierowania (znanego również jako atak typu "człowiek w środku" / MITM). Osoba atakująca może biernie przechwytywać komunikację, dając im dostęp do wszelkich poufnych danych, które są przesyłane, takich jak nazwy użytkowników i hasła. Atakujący może również aktywnie wstrzykiwać / usuwać zawartość z komunikacji, umożliwiając atakującemu fałszowanie i pomijanie informacji, wstrzykiwanie złośliwego skryptu lub powodowanie dostępu klienta do niezaufanej zawartości zdalnej. Atakujący może również przekierować komunikację w taki sposób, że strona internetowa i klient nie komunikują się nawzajem. a; e zamiast tego bez wiedzy komunikują się z atakującym w kontekście innej zaufanej strony.

Słabe Wsparcie Szyfru
Dawniej wysokiej jakości kryptografia była ograniczona do eksportu poza Stany Zjednoczone. Z tego powodu, strony internetowe były skonfigurowane do obsługi słabych kryptograficznych opcji dla tych klientów którzy ograniczali się do używania tylko słabych szyfrów. Słabe szyfry są podatne na atak ze względu na względną łatwość ich złamania; mniej niż dwa tygodnie na typowym komputerze domowym i kilka sekund przy użyciu dedykowanego sprzętu.
Dziś wszystkie nowoczesne przeglądarki i strony internetowe używają o wiele silniejszego szyfrowania, ale niektóre strony wciąż skonfigurowane są do obsługi przestarzałych słabych szyfrów. Z tego powodu atakujący może zmusić klienta do przejścia na słabszy szyfr podczas łączenia się ze stroną internetową, umożliwiając atakującemu złamanie słabego szyfrowania. Z tego powodu, serwer powinien być skonfigurowany do akceptowania tylko silnego szyfrowania i nie gwarantować żadnemu klientowi usługi która wymaga używania słabszego szyfrowania. Ponadto niektóre witryny internetowe są źle skonfigurowane do wyboru słabszego szyfru, nawet jeśli klient będzie obsługiwał znacznie silniejszy. OWASP oferuje przewodnik do testowania problemów związanych z SSL / TLS, w tym obsługę słabych szyfrów i błędną konfigurację, a także inne zasoby i narzędzia.</desc>
	<solution>Faza: Wymagania
Określ wyraźnie, które dane lub materiały są na tyle cenne, że powinny być chronione za pomocą szyfrowania. Wymagaj, aby jakakolwiek transmisja lub przechowywanie tych danych / zasobów korzystało z dobrze sprawdzonych algorytmów szyfrowania.

Faza: Architektura i Projektowanie
Korzystając z modelowania zagrożeń lub innych technik, wyjdź z założenia, że Twoje dane mogą zostać naruszone przez osobną lukę lub słabe punkty i ustal, gdzie szyfrowanie będzie najbardziej skuteczne. Upewnij się, że dane które twoim zdaniem powinny być prywatne nie zostaną nieumyślnie eksponowane z powodu słabości takich jak 
niezabezpieczone uprawnienia (CWE-732).

Faza: Architektura i Projektowanie
Upewnij się, że szyfrowanie jest poprawnie zintegrowane z planem systemu, łącznie z tym, ale niekoniecznie ograniczone do:
      Szyfrowania potrzebnego do przechowywania lub przesyłania prywatnych danych użytkowników systemu
      Szyfrowania potrzebnego do ochrony samego systemu przed nieuprawnionym odsłonięciem lub naruszeniem
Określ oddzielne potrzeby i konteksty szyfrowania:
      Zachodzącego w jednym kierunku (tj. Tylko użytkownik lub odbiorca musi mieć klucz). Można to osiągnąć za pomocą kryptografii klucza publicznego lub innych technik, w których strona kodująca (tj. Oprogramowanie) nie musi mieć dostępu do prywatnego klucza.
      Dwukierunkowe (tj. Szyfrowanie może być automatycznie wykonywane w imieniu użytkownika, ale klucz musi być dostępny, aby otwarty tekst mógł być automatycznie odzyskiwany przez tego użytkownika). Wymaga to przechowywania klucza prywatnego w formacie możliwym do odzyskania tylko przez użytkownika (lub przez system operacyjny) w sposób, który nie może być odzyskany inaczej.

Faza: Architektura i Projektowanie
Nie programuj twoich własnych kryptograficznych algorytmów. Prawdopodobnie będą narażone na ataki, które kryptografowie dobrze rozumieją. Techniki projektowania opartego na analizie konstrukcji są poddane procesowi dojrzewania. Jeśli Twój algorytm może zostać zagrożony i jeśli napastnik dowie się, jak to działa, jest on szczególnie słaby.

Faza: Architektura i Projektowanie
Wybierz dobrze sprawdzony algorytm, który jest obecnie uważany za mocny przez ekspertów w tej dziedzinie i wybierz dobrze przetestowane implementacje.
Na przykład, systemu rządu USA wymagają poświadczenia FIPS 140-2.
Tak jak ze wszystkimi kryptograficznymi mechanizmami, kod źródłowy powinien być dostępny dla analiz.
Co jakiś czas upewnij się, że nie używasz przestarzałej kryptografii. Niektóre starsze algorytmy, o których sądzono kiedyś, że wymagają miliardów lat czasu obliczeniowego, mogą teraz zostać złamane w ciągu kilku dni lub godzin. Obejmuje to MD4, MD5, SHA1, DES i inne algorytmy, które były kiedyś uważane za silne.

Faza: Architektura i Projektowanie
Podziel system na "bezpieczne" obszary, w których można jednoznacznie narysować granice zaufania. Nie pozwól poufnym danym wyjść poza granice zaufania i zawsze uważaj podczas kontaktowania się z przedziałem poza bezpiecznym obszarem.

Fazy: Implementacja; Architektura i Projektowanie
Kiedy używasz technik zatwierdzonych przez branżę, musisz używać ich poprawnie. Nie tnij zakrętów, pomijając etapy wymagające dużej ilości zasobów (CWE-325). Te kroki są często niezbędne do zapobiegania typowym atakom.

Faza: Implementacja
Użyj konwencji nazewnictwa i wyraźnych czcionek, aby łatwiej było wykryć, kiedy używane są poufne dane. Podczas tworzenia struktur, obiektów lub innych złożonych elementów należy jak najdokładniej rozdzielić dane jawne i niejawne.
Ułatwia to wychwycić miejsca w kodzie, w którym używane są dane, które nie są zaszyfrowane.</solution>
	<reference>http://projects.webappsec.org/Insufficient-Transport-Layer-Protection</reference>
	<reference>http://cwe.mitre.org/data/definitions/311.html</reference>
</vuln_item_wasc_4>

<vuln_items>wasc_5</vuln_items>
<vuln_item_wasc_5>
	<alert>Zdalne włączanie plików</alert>
	<desc>Zdalne włączanie plików (RFI) jest techniką ataku wykorzystująca mechanizmy "dynamicznego włączania plików" w aplikacjach internetowych. Gdy aplikacje internetowe przejmują dane wprowadzane przez użytkownika (adres URL, wartość parametru itp.) I przekazują je do plików, które zawierają polecenia, aplikacja internetowa może zostać wykorzystana do dołączenia zdalnych plików za pomocą złośliwego kodu.

Prawie wszystkie struktury aplikacji internetowych obsługują inkluzje plików. Inkluzja plików jest głównie używana do paczkowania zwykłego kodu w oddzielne pliki. które później są odniesione przez główne moduły aplikacji. Kiedy aplikacja internetowa odwołuje się do dołączonego pliku, kod w tym pliku może być wykonywany bezpośrednio lub pośrednio, wywołując określone procedury. Jeśli wybrany moduł do ładowania jest oparty na elementach z żądania HTTP, aplikacja internetowa może być podatna na RFI.
Napastnik może użyć RFI dla:
    * Uruchamiania szkodliwego kodu na serwerze: dowolny kod w załączonych złośliwych plikach będzie uruchamiany przez serwer. Jeśli objęty plik nie jest wykonywany za pomocą jakiejś osłony, kod w objętych plikach jest wykonywany w kontekście użytkownika serwera. Może to prowadzić do całkowitego kompromisu systemowego.
    * Uruchamianie złośliwego kodu u klientów: złośliwy kod hakera może manipulować zawartością odzewu do klienta. The attacker can embed malicious code in the response that will be run by the client (for example, JavaScript to steal the client session cookies).

PHP jest szczególnie podatne na ataki RFI ze względu na szerokie zastosowanie "plik obejmuje" w programowaniu PHP i ze względu na domyślne konfiguracje serwerów, które zwiększają podatność na atak RFI.</desc>
	<solution>Faza: Architektura i Projektowanie
Kiedy zbiór akceptowalnych obiektów, takich jak nazwy plików lub adresy URL, jest ograniczony lub rozpoznany, utwórz odwzorowanie ze zbioru stałych wartości wejściowych (takich jak identyfikatory numeryczne) do rzeczywistych nazw plików lub adresów URL i odrzuć wszystkie inne dane wejściowe.
Na przykład, ID 1 może być wzorowany na "inbox.txt" i ID 2 może być wzorowany na "profile.txt". Funkcje takie jak ESAPI AccessReferenceMap dają taką możliwość.

Fazy: Architektura i Projektowanie; Obsługa
Uruchom swój kod w "więzieniu" lub podobnym testowym środowisku, które wymusza ścisłe granice między procesem a systemem operacyjnym. Może to skutecznie ograniczyć, które pliki mogą być dostępne w określonym katalogu lub które polecenia mogą być wykonywane przez twoje oprogramowanie.
Przykłady poziomu OS obejmujące Unix chroot jail, AppArmor, and SELinux. Na zasadach ogólnych, zarządzany kod może zapewnić pewną ochronę. Na przykład,, java.io.FilePermission w Menadżerze Ochrony Javy umożliwia ci sprecyzować ograniczenia odnośnie operacji na plikach.
To może nie być wykonalne rozwiązanie i ogranicza wpływ tylko na system operacyjny; reszta aplikacji może wciąż być podatna na zagrożenie.
Zachowaj ostrożność przy omijaniu CWE-243 i innych słabości powiązanych z więzieniami.
Dla PHP, interpreter oferuje ograniczenia takie jak otwarty katalog bazowy lub bezpieczny tryb który może utrudnić hakerowi wydostać się z aplikacji. Weźmy pod uwagę także Suhosin, zahartowane rozszerzenie PHP, które wprowadza różne opcje, które blokują niektóre z bardziej niebezpiecznych funkcji PHP.

Faza: Implementacja
Zakładaj, że wszystkie dane wejściowe są szkodliwe. Use an "accept known good" input validation strategy, i.e., use an allow list of acceptable inputs that strictly conform to specifications. Odrzucaj wszystkie dane wejściowe, które nie są ściśle dopasowane ze specyfikacjami lub przeobraź je w takie, które są dopasowane. Do not rely exclusively on looking for malicious or malformed inputs (i.e., do not rely on a deny list). However, deny lists can be useful for detecting potential attacks or determining which inputs are so malformed that they should be rejected outright.
Kiedy przeprowadzasz weryfikację danych wejściowych, bierz pod uwagę wszystkie potencjalnie ważne właściwości, włączając długość, pełny zasięg akceptowalnych wartości, brakujących lub dodatkowych danych wejściowych, zgodność poprzez ważne pola i dostosowanie się do zasad sprawy. As an example of business rule logic, "boat" may be syntactically valid because it only contains alphanumeric characters, but it is not valid if you are expecting colors such as "red" or "blue."
For filenames, use stringent allow lists that limit the character set to be used. Jeśli to możliwe, zezwól tylko na pojedynczy "." znak w nazwie pliku, aby uniknąć słabości, takich jak CWE-23, i wykluczyć separatory katalogów, takie jak "/", aby uniknąć CWE-36. Use an allow list of allowable file extensions, which will help to avoid CWE-434.

Fazy: Architektura i Projektowanie; Obsługa
Jeśli to możliwe, przechowuj biblioteki, pliki dodatkowe i pliki użytkowe poza głównym katalogiem dokumentów internetowych. W przeciwnym razie przechowuj je w oddzielnym katalogu i użyj funkcji kontroli dostępu serwera internetowego, aby uniemożliwić atakującym bezpośrednie żądanie ich. Jedną z powszechnych praktyk jest zdefiniowanie zdeterminowanej stałej w każdym programie wywołującym, a następnie sprawdzenie istnienia stałej w bibliotece/objętym pliku; jeśli stała nie istnieje, to plik został zażądany bezpośrednio i może natychmiast wyjść.
To znacznie redukuje szanse hakera, który może obejść każde mechanizmy obronne, które są w podstawie programu, ale nie w aktach. To także zredukuje twój powierzchniowy atak.

Fazy: Architektura i Projektowanie; Implementacja
Zrozum wszystkie potencjalne obszary gdzie niezaufane dane wejściowe wejdą w twoje oprogramowanie: parametry lub argumenty, ciasteczka, jakikolwiek odczyt z sieci, zmiennych środowiskowych, wyszukiwania wstecznego DNS, wyniki zapytania, nagłówki żądań, komponenty URL, e-mail, pliki, bazy danych i dowolne zewnętrzne
systemy, które dostarczają dane do aplikacji. Pamiętaj o tym, że takie dane wejściowe mogą uzyskane poprzez wezwania API.
Wiele problemów inkluzji plików pojawiają się, ponieważ programista zakłada, że niektóre dane wejściowe nie mogą być modyfikowane, a zwłaszcza dla ciasteczek i komponentów URL.</solution>
	<reference>http://projects.webappsec.org/Remote-File-Inclusion</reference>
	<reference>http://cwe.mitre.org/data/definitions/98.html</reference>
</vuln_item_wasc_5>

<vuln_items>wasc_6</vuln_items>
<vuln_item_wasc_6>
	<alert>Łańcuch formatujący</alert>
	<desc>Ataki Łańcucha Formatującego zmieniają przepływ aplikacji, używając funkcji wyświetlania formatu biblioteki, aby uzyskać dostęp do innej przestrzeni pamięci. Wrażliwość występuje, gdy dane dostarczane przez użytkownika są używane bezpośrednio jako łańcucha formatującego dla niektórych funkcji C / C ++ (na przykład fprintf, printf, sprintf, setproctitle, syslog, ...).

Jeśli haker przejdzie przez łańcuch formatujący składający się ze znaków konwersji printf(n.p. "%f", "%p", "%n",  itd.) jako wartość parametru do aplikacji internetowej, może:
    *Uruchomić dowolny kod na serwerze 
    *Odczytać wartości ze sterty
    *Spowodować segmentację defektu/zepsucia oprogramowania

Ataki łańcucha formatującego są zależne od innych ataków w Klasyfikacji Zagrożeń: Przepełnienia bufora i przepełnienia liczb całkowitych. Wszystkie trzy opierają się na zdolności manipulowania pamięcią lub jej interpretacji w sposób, który przyczynia się do osiągnięcia celu atakującego.</desc>
	<solution>Faza: Wymagania
Wybierz język, który nie jest podatny na tą usterkę.

Faza: Implementacja
Upewnij się, że wszystkie funkcje łańcucha formatującego są przekazywane statycznym ciągiem, który nie może być kontrolowany przez użytkownika i że odpowiednia liczba argumentów jest zawsze wysyłana również do tej funkcji. Jeśli to możliwe, użyj funkcji, które nie obsługują operatora% n w łańcuchach formatujących.
Budowa: Przestrzegaj ostrzeżeń kompilatorów i łączników, ponieważ mogą one ostrzegać o niewłaściwym użytkowaniu.
</solution>
	<reference>http://projects.webappsec.org/Format-String</reference>
	<reference>http://cwe.mitre.org/data/definitions/134.html</reference>
</vuln_item_wasc_6>

<vuln_items>wasc_7</vuln_items>
<vuln_item_wasc_7>
	<alert>Przepełnienie bufora</alert>
	<desc>Przepełnienie Bufora jest usterką, która pojawia się kiedy więcej danych jest wpisanych w blok pamięci lub bufor, wtedy bufor jest przeznaczony do ładowania. Wykorzystanie przepełnienia bufora pozwala intruzowi modyfikować fragmenty przestrzeni adresowej procesu docelowego. This ability can be used for a number of purposes, including the following:
    *Kontrolowanie wykonywania procesu
    *Przerwania procesu
    *Modyfikowania wewnętrznych zmiennych. Osiąga się to poprzez identyfikację wskaźnika funkcji w pamięci, który można modyfikować, bezpośrednio lub pośrednio, za pomocą przepełnienia. Gdy taki wskaźnik jest używany przez program do kierowania wykonywaniem programu za pomocą instrukcji skoku lub wywołania, zostanie użyta lokalizacja instrukcji dostarczona przez napastnika, umożliwiając atakującemu kontrolę procesu.

W wielu przypadkach, funkcja wskaźnika jest zmodyfikowana do referencji lokacji gdzie haker umieścił zgromadzone instrukcje określonego urządzenia. Instrukcje te są powszechnie nazywane kodami powłoki, w związku z faktem, że atakujący często chcą utworzyć środowisko wiersza polecenia lub powłokę w kontekście działającego procesu.

Przepełnienie bufora jest najczęściej kojarzone z oprogramowaniem napisanym w językach programowania C i C ++ ze względu na ich szerokie zastosowanie i możliwość bezpośredniego manipulowania pamięcią przy użyciu powszechnych konstrukcji programistycznych. Jednakże podkreślmy, że przepełnienie bufora może występować w każdym środowisku programistycznym gdzie bezpośrednia manipulacja pamięcią jest dozwolona, czy to przez usterkę w kompilatorze, czasu trwania bibliotek lub funkcji samego języka.
</desc>
	<solution>Faza: Wymagania
Używaj języka, który nie zezwala na wystąpienie tego osłabienia lub zapewnia konstrukcje, które ułatwiają uniknięcie tego osłabienia.
Na przykład wiele języków wykonujących własne zarządzanie pamięcią, takich jak Java i Perl, nie podlega przepełnieniom bufora. Inne języki, takie jak Ada i C #, zwykle zapewniają ochronę przed przepełnieniem, ale programista może ją wyłączyć.
Należy uważać, aby interfejs języka do macierzystego kodu nadal podlegał przepełnieniu, nawet jeśli sam język jest teoretycznie bezpieczny.

Faza: Architektura i Projektowanie
Używaj sprawdzonej biblioteki lub struktury, które nie pozwalają na wystąpienie tego osłabienia lub wprowadzają konstrukcje, które sprawiają, że to osłabienie jest łatwiejsze do uniknięcia.
Przykłady obejmują bibliotekę Safe C String (SafeStr) firmy Messier i Viega oraz bibliotekę Strsafe.h firmy Microsoft. Te biblioteki zapewniają bezpieczniejsze wersje podatne na przepełnienia funkcji operacji na łańcuchach. To nie jest całkowite rozwiązanie, ponieważ wiele przepełnień bufora nie jest powiązanych z łańcuchami.

Faza: Budowa i i Kompilacja
Uruchamiaj lub kompiluj twoje oprogramowanie używając funkcji lub rozszerzeń, które automatycznie zapewniają ochronne mechanizmy, które zmniejszają lub eliminują przepełnienie bufora.
Na przykład, niektóre kompilatory i rozszerzenia udostępniają automatyczne mechanizmy wykrywania przepełnienia bufora, które są wbudowane w skompilowany kod. Przykłady obejmują Microsoft Visual Studio /GS flag, Fedora/Red Hat FORTIFY SOURCE GCC flag, StackGuard, and ProPolice.

Faza: Implementacja
Podczas alokowania pamięci aplikacji i zarządzania nią należy wziąć pod uwagę następujące zasady:
      Sprawdź dwa razy, że twój bufor jest duży jak opisujesz.
      Podczas korzystania z funkcji akceptujących liczbę bajtów do skopiowania, takich jak strncpy (), należy pamiętać, że jeśli rozmiar bufora docelowego jest równy rozmiarowi bufora źródłowego, może nie zakończyć się ciągiem NULL.
      Sprawdź granice buforu jeśli używasz tej funkcji w pętli i upewnij się, że nie jesteś w niebezpieczeństwie zapisu poza przydzieloną przestrzenią.
      Jeśli to konieczne, skróć wszystkie ciągi wejściowe do rozsądnej długości przed przekazaniem ich do funkcji kopiowania i konkatenacji.

Faza: Obsługa
Używaj funkcji takiej jak Address Space Layout Randomization (ASLR).

Faza: Obsługa

Używaj procesora i systemu operacyjnego, który ofiaruje Uruchamiania Ochrony Danych (NX) lub jest to równoważne.

Faza: Implementacja

Zamień nieograniczone kopie funkcji z analogicznymi funkcjami, które wspierają długość argumentów takich jak strcpy z strncpy. Jeśli nie są dostępne, stwórz je.
</solution>
	<reference>http://projects.webappsec.org/Buffer-Overflow</reference>
	<reference>http://cwe.mitre.org/data/definitions/119.html</reference>
</vuln_item_wasc_7>

<vuln_items>wasc_8</vuln_items>
<vuln_item_wasc_8>
	<alert>Cross-site Scripting</alert>
	<desc>Cross-site Scripting (XSS) to technika ataku, która polega na odbiorze kodu dostarczonego przez osobę atakującą do instancji przeglądarki użytkownika. Przykładem przeglądarki może być standardowy klient przeglądarki internetowej lub wbudowany w oprogramowaniu obiekt wyszukiwarki taki jak przeglądarka w WinAmpie, czytniku RSS lub klient e-maila. Sam kod jest zwykle napisany w HTML/JavaScripcie, ale też rozszerzony o VBScript, ActiveX, Jave, Flasha lub jakąkolwiek inną technologię obsługującą przeglądarki.
Jeśli haker zdobędzie przeglądarkę użytkownika do wykonywania jego/jej kodu, to kod zostanie uruchomiony w kontekście(lub strefie) bezpieczeństwa hostującej strony internetowej. Z takim poziomem przywileju, kod ma możliwość czytania, modyfikowania i transmitowania jakichkolwiek dostępnych danych poprzez przeglądarkę. Użytkownik używający skryptów krzyżowych może zostać przejęty przez swoje konto (kradzież plików cookie), przeglądarka zostanie przekierowana do innej lokalizacji lub może zostać dostarczona fałszywa zawartość przez odwiedzaną witrynę internetową. Ataki typu "cross-site scripting" zasadniczo naruszają kredyt zaufania między użytkownikiem a witryną internetową. Aplikacje wykorzystujące instancje obiektów przeglądarki, które ładują zawartość z systemu plików, mogą wykonywać kod zgodnie zlokalną strefą maszyny, co pozwala na naruszenie systemu.

Są trzy typy ataków Cross-site Scripting: nieustępliwy, ustępliwy i oparty na DOM.
Ustępliwe ataki i ataki oparte na domenie DOM wymagają od użytkownika odwiedzenia specjalnie zrobionego ręcznie linku ze złośliwym kodem lub odwiedzenia złośliwej strony internetowej zawierającej formularz internetowy, który po opublikowaniu w narażonej witrynie spowoduje atak. Używanie złośliwej formy często ma miejsce, gdy narażony na atak zasób akceptuje tylko żądania HTTP POST. W takim wypadku, forma może być podporządkowany automatycznie, bez wiedzy ofiary(n.p poprzez użycie JavaScriptu). Po kliknięciu szkodliwego linku lub przesłaniu złośliwego formularza, ładunek XSS zostanie wysłany z powrotem i zostanie zinterpretowany przez przeglądarkę użytkownika i wykonany. Inną techniką do wysyłania niemal bezwzględnych żądań(DOSTAĆ i WYSŁAĆ) jest poprzez użycie wbudowany klient, taki jak Adobe Flash.
Trwałe ataki pojawiają się kiedy złośliwy kod jest wysyłany do witryny gdzie jest przechowywany przez jakiś okres czasu. Przykłady ulubionych celów hakerów obejmują posty wiadomości na tablicy, maile i oprogramowanie czatu witryny. Nic nie podejrzewający użytkownik nie musi wchodzić w interakcję z żadną dodatkową witryną / linkiem (np. Stroną atakującą lub złośliwym linkiem wysłanym za pośrednictwem poczty elektronicznej), wystarczy po prostu przejrzeć stronę internetową zawierającą kod.</desc>
	<solution>Faza: Architektura i Projektowanie
Używaj sprawdzonej biblioteki lub struktury, które nie pozwalają na wystąpienie tego osłabienia lub wprowadzają konstrukcje, które sprawiają, że to osłabienie jest łatwiejsze do uniknięcia.
Przykłady bibliotek i szkieletów, które sprawiają, że łatwiej jest generować poprawnie zaszyfrowane dane wyjściowe obejmujące bibliotekę Anti-XSS microsofta, zaszyfrowany moduł ESAPI i Bramkę Apache.

Fazy: Implementacja; Architektura i Projektowanie
Zapoznaj się z kontekstem, w którym będą używane twoje dane i kodowaniem, jakiego się spodziewasz. Jest to zwłaszcza ważne kiedy dane są transmitowane pomiędzy różnymi komponentami lub kiedy generowane są dane wyjściowe, które zawierają wielokrotne szyfrowanie w tym samym czasie, tak jak strony internetowe albo kilkuczęściowe wiadomości e-mail. Zbadaj wszystkie przewidywane protokoły komunikacyjne i reprezentacje danych, aby określić wymagane strategie kodowania.
W przypadku danych, które będą wysyłane na inną stronę internetową, w szczególności wszelkie dane otrzymane z zewnętrznych źródeł, należy zastosować odpowiednie kodowanie na wszystkich niealfanumerycznych znakach.
Zapoznaj się z Arkuszem Zapobiegania Oszustwa XSS, aby uzyskać więcej informacji na temat typów kodowania i ucieczki, które są potrzebne.

Faza: Architektura i Projektowanie
W przypadku wszelkich kontroli bezpieczeństwa przeprowadzanych po stronie klienta należy upewnić się, że kontrole te są duplikowane po stronie serwera, aby uniknąć CWE-602. Hakerzy mogą obejść kontrole po stronie klienta, modyfikując wartości po przeprowadzeniu kontroli lub zmieniając klienta, aby całkowicie usunąć kontrole po stronie klienta. Następnie te zmodyfikowane wartości zostaną przesłane do serwera.

Jeśli możliwe, używaj wymodelowane mechanizmy automatycznie wymuszające oddzielenie danych i kodu. Te mechanizmy mogą być w stanie zapewnić odpowiednie cytowanie, kodowanie i sprawdzanie poprawności automatycznie, zamiast polegać na programistach, aby zapewnić tę możliwość w każdym punkcie, w którym generowane są dane wyjściowe.

Faza: Implementacja
Dla każdej wygenerowanej strony internetowej użyj i określ kodowanie znaków, takie jak ISO-8859-1 lub UTF-8. Jeśli kodowanie nie jest określone, przeglądarka internetowa może wybrać inne kodowanie, zgadując, które kodowanie jest faktycznie używane na stronie internetowej. Może to spowodować, że przeglądarka traktuje określone sekwencje jako wyjątkowe, otwierając klienta na subtelne ataki XSS. Zobacz CWE-116, aby dowiedzieć się więcej o ograniczeniach związanych z kodowaniem / ucieczką.

Aby zmniejszyć ataki XSS na sesję pliku ciasteczek, ustaw plik sesji ciastecze jako HttpOnly. W przeglądarkach obsługujących funkcję HttpOnly (takich jak nowsze wersje przeglądarki Internet Explorer i Firefox) ten atrybut może uniemożliwić dostęp do pliku sesji ciasteczek użytkownika szkodliwym skryptom po stronie klienta, które używają document.cookie. Nie jest to całkowite rozwiązanie, ponieważ HttpOnly nie jest obsługiwany przez wszystkie przeglądarki. Co ważniejsze, XMLHTTPRequest i inne zaawansowane technologie przeglądarek zapewniają dostęp do odczytu dla nagłówków HTTP, w tym nagłówek Set-Cookie, w którym ustawiona jest flaga HttpOnly.

Zakładaj, że wszystkie dane wejściowe są szkodliwe. Use an "accept known good" input validation strategy, i.e., use an allow list of acceptable inputs that strictly conform to specifications. Odrzucaj wszystkie dane wejściowe, które nie są ściśle dopasowane ze specyfikacjami lub przeobraź je w takie, które są dopasowane. Do not rely exclusively on looking for malicious or malformed inputs (i.e., do not rely on a deny list). However, deny lists can be useful for detecting potential attacks or determining which inputs are so malformed that they should be rejected outright.

Kiedy przeprowadzasz weryfikację danych wejściowych, bierz pod uwagę wszystkie potencjalnie ważne właściwości, włączając długość, pełny zasięg akceptowalnych wartości, brakujących lub dodatkowych danych wejściowych, zgodność poprzez ważne pola i dostosowanie się do zasad sprawy. As an example of business rule logic, "boat" may be syntactically valid because it only contains alphanumeric characters, but it is not valid if you are expecting colors such as "red" or "blue."

Ensure that you perform input validation at well-defined interfaces within the application. Pomoże to chronić aplikację, nawet jeśli komponent zostanie ponownie wykorzystany lub przeniesiony gdzie indziej.
	</solution>
	<reference>http://projects.webappsec.org/Cross-Site-Scripting</reference>
	<reference>http://cwe.mitre.org/data/definitions/79.html</reference>
</vuln_item_wasc_8>

<vuln_items>wasc_9</vuln_items>
<vuln_item_wasc_9>
	<alert>Cross Site Request Forgery</alert>
	<desc>Cross-site request forgery jest atakiem, który obejmuje zmuszanie ofiary do wysłania żądania HTTP do miejsca celowego bez ich wiedzy lub intencji w celu przeprowadzenia akcji jako ofiara. Podstawową przyczyną jest powtarzalność działania aplikacji z przewidywalnymi adresami URL / formularzami. Charakterem ataku jest to, że CSRF wykorzystuje zaufanie, jakie witryna darzy użytkownika. Natomiast skrypty cross-site scripting (XSS) wykorzystują zaufanie, jakim użytkownik darzy stronę internetową. Podobnie jak w przypadku XSS, ataki CSRF niekoniecznie muszą być przekierowane na drugą stronę, ale mogą być. Cross-site request forgery jest również znane jako CSRF, XSRF, atak za jednym kliknięciem, jazda na sesjach, zdezorientowany delegat i surfowanie po morzu.

Ataki CSRF są skuteczne w wielu sytuacjach, w tym:
    * Ofiara ma aktywną sesję w witrynie docelowej.
    * Ofiara jest uwierzytelniona za pośrednictwem protokołu HTTP w witrynie docelowej.
    * Ofiara jest w tej samej sieci lokalnej co strona docelowa.

CSRF został użyty przede wszystkim do wykonania akcji przeciwko witrynie docelowej z wykorzystaniem przywilejów ofiary, ale odkryto najnowsze techniki udostępniania informacji poprzez uzyskanie dostępu do odpowiedzi. Ryzyko udostępnienia informacji dramatycznie wzrasta kiedy strona celu jest podatna na XSS, ponieważ XSS może być użyty jako platforma dla CSRF, włączając w to atak obsługiwany w granicach polityki tego samego pochodzenia.</desc>
	<solution>Faza: Architektura i Projektowanie
Używaj sprawdzonej biblioteki lub struktury, które nie pozwalają na wystąpienie tego osłabienia lub wprowadzają konstrukcje, które sprawiają, że to osłabienie jest łatwiejsze do uniknięcia.
Na przykład, używaj pakietów anty-CSRF takich jak OWASP CSRFGuard.

Faza: Implementacja
Upewnij się, że twoja aplikacja jest wolna od kwestii cross-site scripting, ponieważ większość obron CSRF mogą być ominięte przez kontrolowany przez atakującego skrypt.

Fazy: Architektura i Projektowanie
Wygeneruj unikalny numer dla każdego formularza, umieść go w formularzu i zweryfikuj wartość jednorazową po otrzymaniu formularza. Upewnij się, że liczba nie będzie przewidywalna (CWE-330).
Zwróć uwagę na to, że może to być ominięte używając XSS.

Identyfikuj zwłaszcza niebezpieczne działania. Kiedy użytkownik przeprowadza niebezpieczną operację, wyślij odrębne żądanie potwierdzenia by upewnić się, że użytkownik jest przeznaczony do przeprowadzenia tego działania.
Zwróć uwagę na to, że może to być ominięte używając XSS.

Używaj regulacji Zarządzania Sesją ESAPI.
Ta kontrola obejmuje komponent dla CSRF.

Nie używaj metody GET dla żadnego żądania, która uruchamia zmianę stanu.

Faza: Implementacja
Sprawdź nagłówek HTTP Referer, aby sprawdzić, czy żądanie pochodzi z oczekiwanej strony. To mogłoby przerwać prawowitą funkcjonalność, ponieważ użytkownicy lub proxy mogłyby zostać wyłączone wysyłając dla Referer prywatnych powodów.</solution>
	<reference>http://projects.webappsec.org/Cross-Site-Request-Forgery</reference>
	<reference>http://cwe.mitre.org/data/definitions/352.html</reference>
</vuln_item_wasc_9>

<vuln_items>wasc_10</vuln_items>
<vuln_item_wasc_10>
	<alert>Odmowa Usługi</alert>
	<desc>Odmowa Usługi(ang. DoS) jest techniką ataku z zamiarem uniemożliwienia stronie internetowej obsługi normalnej aktywności użytkownika. Ataki DoS, które łatwo można zastosować w warstwie sieciowej, są również możliwe w warstwie aplikacji. Te złośliwe ataki mogą zakończyć się powodzeniem zagrażając systemowi krytycznych zasobów, wykorzystując luki w zabezpieczeniach lub nadużywając funkcjonalność.

Wiele razy ataki DoS będą usiłować zużyć wszystkie dostępne materiały systemowe strony internetowej takie jak: Procesor, pamięć, miejsce na dysku itd. Kiedy którykolwiek z tych krytycznych zasobów osiągnie pełną eksploatację, strona internetowa będzie zazwyczaj niedostępna.

Ponieważ dzisiejsze środowiska aplikacji internetowych obejmują serwer Www, serwer bazy danych i serwer uwierzytelniania, DoS w warstwie aplikacji może być kierowany na każdy z tych niezależnych składników. W przeciwieństwie do DoS w warstwie sieci, gdzie wymagana jest duża liczba prób połączenia, DoS w warstwie aplikacji jest znacznie prostszym zadaniem do wykonania.</desc>
	<solution>Faza: Architektura i Projektowanie

Zaprojektuj mechanizmy tłumienia w architekturze systemu. Najlepszą ochroną jest ograniczenie liczby materiałów, które nieupoważniony użytkownik może zużyć. Silny wzorzec uwierzytelniania i kontroli dostępu zapobiegnie takim atakom w pierwszej kolejności. Aplikacja logowania powinna być chroniona przed atakami DoS tak bardzo, jak to możliwe. Ograniczenie dostępu do bazy danych, być może poprzez buforowanie zestawów wyników, może pomóc zminimalizować eksploatowanie zasobów. Aby jeszcze bardziej ograniczyć możliwość ataku DoS, należy rozważyć śledzenie liczby żądań otrzymanych od użytkowników i blokowanie żądań przekraczających zdefiniowany próg częstotliwości.

Ograniczanie ataków polegających na wyczerpaniu zasobów wymaga, aby system docelowy:
      rozpoznaje atak i odmawia temu użytkownikowi dalszego dostępu przez określony czas, lub
      jednolicie ogranicza wszystkie żądania, aby utrudnić eksploatację zasobów szybciej niż można je ponownie uwolnić. 

Pierwsze z tych rozwiązań jest jednak problemem samym w sobie, ponieważ może pozwolić atakującym na uniemożliwienie korzystania z systemu przez określonego, ważnego użytkownika. Jeśli atakujący podszywa się pod prawomocnego użytkownika, może uniemożliwić mu dostęp do danego serwera.

Drugie rozwiązanie jest po prostu trudne do efektywnego wdrożenia - a nawet jeśli jest właściwie wykonane, nie zapewnia pełnego rozwiązania. Zwyczajnie sprawia, że ​​atak wymaga więcej środków ze strony atakującego.

Upewnij się, że protokoły mają określone ograniczenia w skali plasowanej na nich.

Faza: Implementacja
Upewnij się, że wszystkie awarie alokacji zasobów umieszczają system w bezpiecznej pozycji.</solution>
	<reference>http://projects.webappsec.org/Denial-of-Service</reference>
	<reference>http://cwe.mitre.org/data/definitions/400.html</reference>
</vuln_item_wasc_10>

<vuln_items>wasc_11a</vuln_items>
<vuln_item_wasc_11a>
	<alert>Brutalne Wymuszanie Danych dostępowych</alert>
	<desc>Atak brutalnej siły to metoda określania nieznanej wartości za pomocą zautomatyzowanego procesu w celu wypróbowania dużej liczby możliwych wartości. Atak korzysta na fakcie, że entropia wartości jest mniejsza niż spostrzegana. Na przykład, podczas gdy 8-znakowe alfanumeryczne hasło może mieć 2,8 biliona możliwych wartości, wiele osób wybierze swoje hasła z dużo mniejszego zestawu składającego się z powszechnych słów i terminów.

Najczęstszym rodzajem ataku typu brutalnej siły w aplikacjach internetowych jest atak na dane logowania. Ponieważ użytkownicy muszą pamiętać hasła, często wybierają łatwe do zapamiętania słowa lub wyrażenia jako hasła, dokonując brutalnego ataku przy użyciu słownika. Taki atak usiłujący zalogować się do systemu używając wielkiej listy wyrazów i fraz jako potencjalne hasła, jest często nazywany "atak listy wyrazów" lub "atak ze słownikiem". Próby haseł mogą również zawierać odmiany słów wspólnych dla haseł, takich jak generowane przez zamianę "o" na "0" i "i" na "1", a także dane osobowe, w tym nazwiska członków rodziny, daty urodzenia i numery telefonów.
	</desc>
	<solution>TBA</solution>
	<reference>http://projects.webappsec.org/Brute-Force</reference>
	<reference>TBA</reference>
</vuln_item_wasc_11a>

<vuln_items>wasc_11b</vuln_items>
<vuln_item_wasc_11b>
	<alert>Metoda Brutalnej Siły Identyfikatorów Sesji</alert>
	<desc>Atak brutalnej siły to metoda określania nieznanej wartości za pomocą zautomatyzowanego procesu w celu wypróbowania dużej liczby możliwych wartości. Atak korzysta na fakcie, że entropia wartości jest mniejsza niż spostrzegana. Na przykład, podczas gdy 8-znakowe alfanumeryczne hasło może mieć 2,8 biliona możliwych wartości, wiele osób wybierze swoje hasła z dużo mniejszego zestawu składającego się z powszechnych słów i terminów.

Ponieważ HTTP jest protokołem bezstanowym, w celu utrzymania stanu, aplikacje internetowe muszą zapewnić, że identyfikator sesji jest wysyłany przez przeglądarkę przy każdym żądaniu. Identyfikator sesji jest najczęściej przechowywany w pliku cookie lub adresie URL protokołu HTTP. Używając metody ataku brutalnej siły, osoba atakująca może odgadnąć identyfikator sesji innego użytkownika. Może prowadzić to do podawania się hakera za użytkownika, wyszukania osobistych informacji i przeprowadzenia działań w imieniu użytkownika.
	</desc>
	<solution>TBA</solution>
	<reference>http://projects.webappsec.org/Brute-Force</reference>
	<reference>TBA</reference>
</vuln_item_wasc_11b>

<vuln_items>wasc_11c</vuln_items>
<vuln_item_wasc_11c>
	<alert>Metoda Brutalnej Siły Katalogi i Pliki</alert>
	<desc>Atak brutalnej siły to metoda określania nieznanej wartości za pomocą zautomatyzowanego procesu w celu wypróbowania dużej liczby możliwych wartości. Atak korzysta na fakcie, że entropia wartości jest mniejsza niż spostrzegana. Na przykład, podczas gdy 8-znakowe alfanumeryczne hasło może mieć 2,8 biliona możliwych wartości, wiele osób wybierze swoje hasła z dużo mniejszego zestawu składającego się z powszechnych słów i terminów.

Gdy pliki znajdują się w katalogach obsługiwanych przez serwer sieciowy, ale nie są połączone w żaden sposób, uzyskanie dostępu do tych plików wymaga znajomości ich nazwy. W niektórych przypadkach pliki pozostały porzucone przypadkiem: na przykład zapasowy plik automatycznie stworzony podczas edytowania pliku lub pozostałość po starszej wersji aplikacji webowej. W innych przypadkach pliki zostały zostawione świadomie niepowiązane jako "ochrona przez niejasność": mechanizmy dopuszczają do dostępu tylko tych którzy znają nazwy plików.

Metoda brutalnego ataku próbuje zlokalizować niepołączony plik poprzez próbowanie uzyskania dostępu do dużych liczb plików. Lista dostępnych nazw plików może być pochwycona z listy ze znanych potencjalnych plików lub opartych na wariantach widocznych plików na stronie internetowej. Więcej informacji na temat katalogów i plików metody brutalnego ataku można znaleźć w powiązanych zagrożeniach niebezpieczeństwa, przewidywalnej lokalizacji zasobów.
	</desc>
	<solution>TBA</solution>
	<reference>http://projects.webappsec.org/Brute-Force</reference>
	<reference>TBA</reference>
</vuln_item_wasc_11c>

<vuln_items>wasc_11d</vuln_items>
<vuln_item_wasc_11d>
	<alert>Metoda Brutalnej Siły Informacji Karty Kredytowej</alert>
	<desc>Atak brutalnej siły to metoda określania nieznanej wartości za pomocą zautomatyzowanego procesu w celu wypróbowania dużej liczby możliwych wartości. Atak korzysta na fakcie, że entropia wartości jest mniejsza niż spostrzegana. Na przykład, podczas gdy 8-znakowe alfanumeryczne hasło może mieć 2,8 biliona możliwych wartości, wiele osób wybierze swoje hasła z dużo mniejszego zestawu składającego się z powszechnych słów i terminów.

Zakupy online używając skradzionych kart kredytowych zwykle wymagają podania informacji oprócz numeru karty kredytowej, najczęściej CVV / SCS i / lub daty wygaśnięcia. Oszust może posiadać skradziony numer karty kredytowej bez dodatkowych informacji. Na przykład, CVV/CSC nie jest odciśnięte na karcie lub przechowywane w magnetycznej wypustce więc nie może być zdobyta przez mechaniczne lub magnetyczne urządzenia do przesuwania karty kredytowej.

W celu wypełnienia brakujących informacji, haker może odgadnąć brakujące informacje używając metody brutalnej siły, próbując wszystkich możliwych wartości.
    * Zgadywanie CVV / CSC wymaga tylko 1000 lub 10000 prób, ponieważ ilość cyfr to tylko 3 lub 4, w zależności od rodzaju karty.
    * Zgadywanie daty ważności wymaga jedynie kilka tuzin prób.
	</desc>
	<solution>TBA</solution>
	<reference>http://projects.webappsec.org/Brute-Force</reference>
	<reference>TBA</reference>
</vuln_item_wasc_11d>

<vuln_items>wasc_12</vuln_items>
<vuln_item_wasc_12>
	<alert>Fałszowanie zawartości</alert>
	<desc>Fałszowanie zawartości jest techniką ataku, która pozwala atakującemu wstrzyknąć złośliwe dane właściwe, które są później przeinaczane jako autentyczna wartość aplikacji webowej.
 
Fałszowanie Tylko Zawartości Tekstowej
Powszechną drogą do dynamicznego budowania stron obejmuje przekazywanie treści lub jej części na stronę za pomocą wartości ciągu zapytania. Ta droga jest powszechna na stronach błędów lub na stronach udostępniających historie lub wiadomości. Treść określona w tym parametrze jest później odzwierciedlana na stronie w celu zapewnienia zawartości strony.
 
Odbite Znaczniki W Fałszywej Zawartości.
Niektóre strony internetowe są obsługiwane przy użyciu dynamicznie generowanych źródeł treści HTML. Dla przykładu, źródło ramki "frame" <frame src="http://foo.example/file.html"/>) could be specified by a URL parameter value. (http://foo.example/page?frame_src=http://foo.example/file.html). Osoba atakująca może zastąpić wartość parametru "frame_src" przez "frame_src = http: //attacker.example/spoof.html". W przeciwieństwie do przekierowań, po wyświetleniu wynikowej strony internetowej pasek adresu przeglądarki widocznie pozostaje pod domeną oczekiwaną przez użytkownika (foo.example), ale obce dane (np. atakujący.przykład) są spowite autentycznymi treściami.

Specjalnie zrobione ręcznie linki mogą być wysłane przez e-maila, błyskawiczne wiadomości, pozostawione na tablicach ogłoszeń lub przez użytkowników zmuszonych przez atak Cross-site Scripting. Jeśli atakujący dotrze do użytkownika odwiedzającego stronę internetową zaprogramowaną przez ich złośliwy URL, użytkownik będzie wierzył, że przegląda autentyczną zawartość z jednej lokalizacji co nie jest prawdą. Użytkownicy będą bezgranicznie ufać sfałszowanej zawartości dopóki lokalizacja strony wyświetla http://foo.example, kiedy tak naprawdę ramka HTML jest zaopatrzona w bibliografię http://attacker.example.

Ten atak wykorzystuje relację zaufania założonej pomiędzy użytkownikiem a stroną internetową. Technika była używana do tworzenia fałszywych stron internetowych obejmujących postać loginów, zniszczenia, fałszywe informacje prasowe itd.
	</desc>
	<solution>TBA</solution>
	<reference>http://projects.webappsec.org/Content-Spoofing</reference>
	<reference>TBA</reference>
</vuln_item_wasc_12>

<vuln_items>wasc_13</vuln_items>
<vuln_item_wasc_13>
	<alert>Wyciek Informacji</alert>
	<desc>Wyciek informacji jest słabością aplikacji, w której aplikacja ujawnia poufne dane, takie jak szczegóły techniczne aplikacji internetowej, środowiska lub dane specyficzne dla użytkownika. Poufne dane mogą być użyte przez atakującego do wykorzystania docelowej aplikacji webowej, sieci hostingowej lub jej użytkowników. Dlatego wyciek danych szczególnie chronionych powinien być ograniczony lub uniemożliwiony, o ile jest to możliwe. Wyciek informacji w najbardziej rozpowszechnionej formie wynika z co najmniej jednego z następujących warunków: Nie można wyłuskać komentarzy HTML / Script zawierających poufne informacje, nieprawidłową konfigurację aplikacji lub serwera lub różnice w odpowiedziach strony w przypadku prawidłowych i nieprawidłowych danych.

Brak możliwości wyszukania komentarzy HTML / Skryptu przed przekazaniem do środowiska produkcyjnego może spowodować wyciek poufnych informacji kontekstowych, takich jak struktura katalogów serwera, struktura zapytań SQL i informacje o sieci wewnętrznej. Często programista pozostawia komentarze w kodzie HTML i / lub kodzie skryptu, aby ułatwić proces debugowania lub integracji podczas fazy przedprodukcyjnej. Chociaż nie ma nic złego w zezwalaniu programistom na umieszczanie wstawianych komentarzy w tworzonych przez nich treściach, to te komentarze powinny zostać usunięte przed publicznym opublikowaniem treści.

Numery wersji oprogramowania i szczegółowe komunikaty o błędach (takie jak numery wersji ASP.NET) są przykładami niewłaściwych konfiguracji serwerów. Ta informacja jest przydatna atakującemu, dostarczając szczegółowych informacji o strukturze, językach lub predefiniowanych funkcjach wykorzystywanych przez aplikację internetową. Większość domyślnych konfiguracji serwerów udostępnia numery wersji oprogramowania i szczegółowe komunikaty o błędach do celów debugowania i rozwiązywania problemów. Zmiany w konfiguracji mogą być zrobione do wyłączenia tych funkcji, zapobiegając wyświetlania tych informacji.

Strony, które podają różne odpowiedzi w oparciu o ważność danych, mogą również doprowadzić do wycieku informacji; w szczególności, gdy dane uznane za poufne ujawniają się w wyniku projektu aplikacji internetowej. Przykłady poufnych danych obejmują(ale nie są limitowane): numery kont, identyfikatory użytkowników(Numer prawa jazdy, Numer paszportu, Numery Ubezpieczenia Społecznego itd.) oraz konkretne informacje o użytkownikach (hasła, sesje, adresy). Wyciek informacji w tym kontekście dotyczy ujawnienia kluczowych danych użytkownika uznanych za poufne lub tajne, które nie powinny być ujawniane w zwykłym widoku, nawet dla użytkownika. Numery kart kredytowych i inne ściśle regulowane informacje są pierwszorzędnymi przykładami danych użytkowników, które należy dodatkowo zabezpieczyć przed ujawnieniem lub wyciekiem, nawet przy odpowiednim szyfrowaniu i kontroli dostępu, które już istnieją.</desc>
	<solution>Podziel twój system na "bezpieczne" strefy gdzie zaufane granice mogą być jednoznacznie narysowane. Nie pozwól poufnym danym wyjść poza granice zaufania i zawsze uważaj podczas kontaktowania się z przedziałem poza bezpiecznym obszarem.</solution>
	<reference>http://projects.webappsec.org/Information-Leakage</reference>
	<reference>http://cwe.mitre.org/data/definitions/200.html</reference>
</vuln_item_wasc_13>

<vuln_items>wasc_14</vuln_items>
<vuln_item_wasc_14>
	<alert>Nieprawidłowa Konfiguracja Serwera</alert>
	<desc>Ataki polegające na Nieprawidłowej Konfiguracji Serwera wykorzystują słabości konfiguracji wykryte na serwerach internetowych i serwerach aplikacji. Wiele serwerów zawiera niepotrzebne pliki domyślne i przykładowe, w tym aplikacje, pliki konfiguracyjne, skrypty i strony internetowe. Mogą mieć również włączone niepotrzebne usługi takie jak menadżer zawartości i funkcję zdalnego administrowania. Debugowanie funkcji może być włączone lub funkcje administratora mogą być dostępne dla anonimowych użytkowników. Funkcje te mogą zapewnić hakerom możliwość ominięcia metod uwierzytelniania i uzyskania dostępu do poufnych informacji, być może z podwyższonymi uprawnieniami.

Serwery mogą obejmować dobrze znane standardowe konta oraz hasła. Niepowodzenia w całkowitym zablokowaniu lub zahartowaniu serwera może spowodować niepoprawne ustawienia uprawnień do pliku i katalogu. Błędnie skonfigurowane certyfikaty SSL i ustawienia szyfrowania, użycie domyślnych certyfikatów i niewłaściwa implementacja uwierzytelniania w zewnętrznych systemach może zagrozić poufności informacji.

Wielosłowne i informacyjne komunikaty o błędach mogą skutkować wyciekiem danych, a ujawnione informacje mogą zostać wykorzystane do opracowania następnego poziomu ataku. Nieprawidłowe konfiguracje w oprogramowaniu serwera mogą zezwalać na indeksowanie katalogów i ataki na przemierzanie ścieżek.</desc>
	<solution>TBA</solution>
	<reference>http://projects.webappsec.org/Server-Misconfiguration</reference>
	<reference/>
</vuln_item_wasc_14>

<vuln_items>wasc_15</vuln_items>
<vuln_item_wasc_15>
	<alert>Błędna Konfiguracja Aplikacji</alert>
	<desc>Ataki typu Błędna Konfiguracja Aplikacji wykorzystują słabości konfiguracji wykryte w aplikacjach internetowych. Wiele aplikacji zawiera niepotrzebne i niebezpieczne funkcje, takie jak funkcje debugowania i kontroli jakości, które są domyślnie włączone. Funkcje te mogą zapewnić hakerom możliwość ominięcia metod uwierzytelniania i uzyskania dostępu do poufnych informacji, być może z podwyższonymi uprawnieniami.

Podobnie instalacje domyślne mogą zawierać dobrze znane nazwy użytkowników i hasła, wprowadzone na stałe konta backdoorów, specjalne mechanizmy dostępu i niepoprawne uprawnienia dla plików dostępnych przez serwery Www. Domyślne przykłady mogą być dostępne w środowiskach produkcyjnych. Pliki konfiguracyjne oparte na aplikacjach, które nie są odpowiednio zablokowane, mogą zawierać wyraźne ciągi połączeń tekstowych do bazy danych, a domyślne ustawienia w plikach konfiguracyjnych mogły nie zostać ustawione z myślą o bezpieczeństwie. Wszystkie te błędy konfiguracyjne mogą prowadzić do nieupoważnionego dostępu do poufnych informacji.</desc>
	<solution>TBA</solution>
	<reference>http://projects.webappsec.org/Application-Misconfiguration</reference>
	<reference/>
</vuln_item_wasc_15>

<vuln_items>wasc_16</vuln_items>
<vuln_item_wasc_16>
	<alert>Indeksowanie Katalogu</alert>
	<desc>Automatyczne Zestawienie/Indeksowanie katalogu jest funkcją serwera sieciowego, która zestawia wszystkie pliki w żądanym katalogu jeśli zwykła baza plików (index.html/home.html/default.htm/default.asp/default.aspx/index.php) nie jest aktualna. Gdy użytkownik żąda strony głównej witryny internetowej, zwykle wpisuje adres URL taki jak: http://www.example.com/directory1/ - używając nazwy domeny i wykluczając określony plik. Serwer internetowy przetwarza to żądanie i przeszukuje katalog główny dokumentu w poszukiwaniu domyślnej nazwy pliku i wysyła tę stronę do klienta. Jeśli strona nie jest aktualna, serwer sieciowy dynamicznie wyemituje listing katalogu i wyśle dane wyjściowe do klienta. Przede wszystkim, jest to równorzędne do emitowania komendy "Is"(Unix) lub "dir"(Windows) w tym katalogu i pokazanie wyników w formie HTML. Z punktu widzenia ataku i przeciwdziałania, ważne jest, aby zdać sobie sprawę, że niezamierzone listingi katalogów mogą być możliwe ze względu na luki w oprogramowaniu (omówione w przykładowej sekcji poniżej) w połączeniu z konkretnym żądaniem internetowym.</desc>
	<solution>Zalecenia obejmują ograniczanie dostępu do ważnych katalogów lub plików poprzez przyjęcie wymogu znajomości zarówno dokumentu, jak i katalogu głównego serwera, oraz wyłączanie funkcji, takich jak automatyczne publikowanie katalogów, które mogą ujawniać prywatne pliki i dostarczać informacji, które mogą zostać wykorzystane przez osobę atakującą podczas formułowania lub przeprowadzania ataku.</solution>
	<reference>http://projects.webappsec.org/Directory-Indexing</reference>
	<reference>http://cwe.mitre.org/data/definitions/548.html</reference>
</vuln_item_wasc_16>

<vuln_items>wasc_17</vuln_items>
<vuln_item_wasc_17>
	<alert>Nieprawidłowe Uprawnienia w Systemie Plików</alert>
	<desc>Nieprawidłowe Uprawnienia w Systemie Plików są zagrożeniem dla poufności, integralności i dostępności aplikacji internetowej. Problem powstaje, gdy niepoprawne uprawnienia systemu plików są ustawione na pliki, foldery i symboliczne odnośniki. Kiedy ustawione są nieprawidłowe uprawnienia, haker jest w w stanie dojść do poufnych plików lub katalogów i zmodyfikować albo usunąć ich zawartość. Na przykład, jeśli anonimowy użytkownik konta napisał zezwolenie do pliku, atakujący może zmodyfikować zawartość pliku wpływającego na aplikację webową nieodpowiednimi sposobami. Osoba atakująca może również wykorzystać niewłaściwe dowiązanie symboliczne do eskalacji swoich uprawnień i / lub uzyskać dostęp do nieautoryzowanych plików; na przykład dowiązanie symboliczne wskazujące na katalog spoza katalogu głównego.</desc>
	<solution>Very carefully manage the setting, management and handling of permissions. Jawnie zarządzaj strefami zaufania w oprogramowaniu.</solution>
	<reference>http://projects.webappsec.org/Improper-Filesystem-Permissions</reference>
	<reference>http://cwe.mitre.org/data/definitions/280.html</reference>
</vuln_item_wasc_17>

<vuln_items>wasc_18</vuln_items>
<vuln_item_wasc_18>
	<alert>Predykcja Danych Dostępowych i Sesji</alert>
	<desc>Predykcja Danych Dostępowych i Sesji jest metodą przejęcia lub podszywania się pod użytkownika strony internetowej. Dedukowanie lub odgadywanie unikalnej wartości, która identyfikuje określoną sesję lub użytkownika, dokonuje ataku. Także znana jako Przejmowanie Sesji, konsekwencje mogą umożliwić atakującym wysyłanie żądań ze strony internetowej z przywilejami zaatakowanego użytkownika.

Wiele stron internetowych są zaprojektowane do autoryzacji i śledzenia użytkownika kiedy komunikacja jest pierwszy raz nawiązana. Do zrobienia tego, użytkownicy muszą udowodnić ich tożsamość stronie internetowej, zwykle poprzez podanie kombinacji nazwy/hasła(danych dostępowych). Zamiast przekazywać te poufne poświadczenia w każdej transakcji, strony internetowe będą generować unikalny "identyfikator sesji", aby zidentyfikować sesję użytkownika jako uwierzytelnioną. Późniejsza komunikacja między użytkownikiem a witryną WWW jest oznaczana identyfikatorem sesji jako "dowód" uwierzytelnionej sesji. Jeśli atakujący jest w stanie przewidzieć lub odgadnąć identyfikator sesji innego użytkownika, możliwe jest oszukańcze działanie.</desc>
	<solution>TBA</solution>
	<reference>http://projects.webappsec.org/Credential-and-Session-Prediction</reference>
	<reference/>
</vuln_item_wasc_18>

<vuln_items>wasc_19</vuln_items>
<vuln_item_wasc_19>
	<alert>SQL Injection</alert>
	<desc>SQL Injection jest techniką ataku używaną do wykorzystywania aplikacji które budują oświadczenia SQL od użytkownika dostarczającego dane wejściowe. Gdy to powiedzie się, atakujący będzie mógł zmienić logikę oświadczenia SQL zrealizowanego przeciwko bazie danych.

Wymodelowany Język Query (ang. SQL) jest wyspecjalizowanym językiem programowania do wysyłania kwerendy do baz danych. Język programowania SQL jest standardem ANSI jak i ISO, chociaż wiele produktów baz danych obsługujących SQL robi to z zastrzeżonymi rozszerzeniami standardowego języka. Aplikacje często używają danych dostarczonych przez użytkownika do stworzenia oświadczeń SQL. Jeśli aplikacji nie uda się poprawnie skonstruować oświadczeń SQL, to atakujący może zmienić strukturę oświadczenie i wykonać nieplanowane i potencjalnie wrogie komendy. Kiedy takie komendy zostaną zrealizowane, podejmą działania według zawartości danego użytkownika przez aplikację realizującą oświadczenie. Ta możliwość dopuszcza atakującego do przejęcia kontroli nad zasobami bazy danych dostępnych dla tego użytkownika, włącznie z możliwością wykonywania poleceń w systemie hostingu.</desc>
	<solution>Faza: Architektura i Projektowanie
Używaj sprawdzonej biblioteki lub struktury, które nie pozwalają na wystąpienie tego osłabienia lub wprowadzają konstrukcje, które sprawiają, że to osłabienie jest łatwiejsze do uniknięcia.
Na przykład weź pod uwagę używać trwałe warstwy takie jak Hibernację lub Przedsiębiorstwo Java Beans, które mogą zapewnić znaczącą ochronę przeciwko SQL Incjection jeśli są używane poprawnie.

Jeśli możliwe, używaj wymodelowane mechanizmy automatycznie wymuszające oddzielenie danych i kodu. Te mechanizmy mogą być w stanie zapewnić odpowiednie cytowanie, kodowanie i sprawdzanie poprawności automatycznie, zamiast polegać na programistach, aby zapewnić tę możliwość w każdym punkcie, w którym generowane są dane wyjściowe.

Proces SQL używa przygotowanych oświadczeń, sparametryzowanych pytań lub złożonych procedur. Te funkcje powinny zatwierdzać parametry lub wartości i wspierać silne wprowadzanie tekstu. Nie konstruuj dynamicznie i nie wykonuj ciągów zapytań w tych funkcjach używając "exec" lub podobnych funkcjonalności, ponieważ możesz ponownie wprowadzić sposobność dla SQL Injection.

Uruchom swój kod używając najmniejszych przywilejów, które są wymagane do wykonania koniecznych zadań. Jeśli możliwe, utwórz odizolowane konta z limitowanymi przywilejami, które są używane tylko do pojedynczych zadań. Tą drogą, skuteczny atak nie da gwałtownie dostępu do reszty oprogramowania lub jego środowiska. Na przykład, baza danych aplikacji rzadko musi uruchomić bazę danych administratora zwłaszcza w codziennych operacjach.

W szczególności, postępuj zgodnie z najmniejszymi zasadami kiedy tworzyć konto do bazy danych SQL. Użytkownicy bazy danych powinni mieć tylko minimalne przywileje potrzebne do używania ich kont. Jeśli wymagania systemu wskazują na to, że użytkownik może czytać i modyfikować ich własne dane, ogranicz ich przywileje, żeby nie mogli czytać/pisać danych reszty. Używaj rygorystycznych zezwoleń możliwie na wszystkich obiektach bazy danych, takich jak wykonalnych tylko dla zapisanych procedur.

Faza: implementacja
Jeśli musisz użyć dynamicznie wygenerowanych ciągów zapytać lub komend mimo ryzyka, odpowiednio przytaczaj argumenty i unikaj wszelkich znaków specjalnych w tych argumentach. The most conservative approach is to escape or filter all characters that do not pass an extremely strict allow list (such as everything that is not alphanumeric or white space). Jeśli kilka specjalnych znaków jest potrzebnych, takie jak znak kontrolny, opakuj każdy argumenty w cytat zaraz po kroku unikania/filtrowania. Zachowaj ostrożność przy wstrzykiwaniu argumentów (CWE-88).

Zamiast budować swoją własną implementację, taką jak funkcje mające dostęp do bazy danych lub języku programowania. Na przykład paczka Oracle DBMS ASSERT może sprawdzić lub zmusić, że parametry mające określone właściwości, żeby były mniej podatne na SQL Injection. Dla MySQL, mysql prawdziwe uniknięcie ciągu() funkcji API jest dostępna zarówno jak i dla C i PHP.

Zakładaj, że wszystkie dane wejściowe są szkodliwe. Use an "accept known good" input validation strategy, i.e., use an allow list of acceptable inputs that strictly conform to specifications. Odrzucaj wszystkie dane wejściowe, które nie są ściśle dopasowane ze specyfikacjami lub przeobraź je w takie, które są dopasowane. Do not rely exclusively on looking for malicious or malformed inputs (i.e., do not rely on a deny list). However, deny lists can be useful for detecting potential attacks or determining which inputs are so malformed that they should be rejected outright.

Kiedy przeprowadzasz weryfikację danych wejściowych, bierz pod uwagę wszystkie potencjalnie ważne właściwości, włączając długość, pełny zasięg akceptowalnych wartości, brakujących lub dodatkowych danych wejściowych, zgodność poprzez ważne pola i dostosowanie się do zasad sprawy. As an example of business rule logic, "boat" may be syntactically valid because it only contains alphanumeric characters, but it is not valid if you are expecting colors such as "red" or "blue."

When constructing SQL query strings, use stringent allow lists that limit the character set based on the expected value of the parameter in the request. To bezpośrednio ograniczy zakres ataku, jednakże ta technika jest mniej ważna niż poprawne kodowanie i unikanie danych wyjściowych.

Miej na uwadze, że poprawne kodowanie danych wyjściowych, unikanie i cytowanie są najbardziej efektywnymi solucjami do zapobiegania SQL Injection, aczkolwiek weryfikacja danych wejściowych mogą zapewnić dogłębną obronę. Dzieje się tak, ponieważ skutecznie ogranicza to, co pojawi się w danych wyjściowych. Weryfikacja danych wejściowych nie będzie zawsze zapobiegać SQL Injection, zwłaszcza jeśli jesteś żadany do obsługiwania wolnej formy pól tekstu, która może zawierać przypadkowe znaki. Na przykład, nazwa "O'Reilly" prawdopodobnie przejdzie krok weryfikacji, ponieważ jest to powszechne nazwisko w języku angielskim. Jednakże, nie może to być bezpośrednio wprowadzone do bazy danych, ponieważ zawiera znak apostrofu "", który musi być pominięty lub inaczej wprowadzony. W takim przypadku, ściągniecie apostrofu może zredukować ryzyko SQL Injection, ale będzie tworzyć niepoprawne postępowanie ponieważ będzie zarejestrowana zła nazwa.

Jeśli jest to możliwe do zrealizowania, najbezpieczniejszym sposobem będzie zupełne blokowanie ponad-znaków, zamiast ich omijania. Zapewni to pewną gruntowną defensywę. Po tym jak dane będą wprowadzone do bazy danych, procesy następnie mogą lekceważyć omijanie ponad-znaków przed użyciem, a ty możesz nie mieć kontroli nad tymi procesami.</solution>
	<reference>http://projects.webappsec.org/SQL-Injection</reference>
	<reference/>
</vuln_item_wasc_19>

<vuln_items>wasc_20</vuln_items>
<vuln_item_wasc_20>
	<alert>Niepoprawna Obsługa Danych Wejściowych</alert>
	<desc>Niepoprawna Obsługa Danych Wejściowych jest dzisiaj jedną z najpowszechniejszych osłabień zidentyfikowanych przez aplikacje. Słabe obsługa danymi wejściowymi prowadzi do spowodowania krytycznych zagrożeń bezpieczeństwa powstających w systemie i aplikacjach.
	
Generalnie, termin obsługa danych wejściowych jest używany do opisania funkcji takich jak weryfikacja, sanityzacja, kodowanie i/lub dekodowanie danych wejściowych. Aplikacje otrzymują dane wejściowe z różnych źródeł obejmujących ludzkich użytkowników, agentów oprogramowania(wyszukiwarek) i źródeł sieci/obwodowych do nazwania niektórych. W przypadku aplikacji webowych, dane wejściowe mogą być transferowane w różnych formatach (nazwa par wartości, JSON, SOAP, itd...) i nabytych przez ciągi zapytań, danych POSTÓW, nagłówki HTTP, Ciasteczka, itd... Dane wejściowe aplikacji nie-webowych mogą być otrzymane poprzez zmienne aplikacji, zmienne środowiskowe, rejestrację, pliki konfiguracyjne itd... Niezależnie od formatu danych lub źródła/lokacji danych wejściowych, wszystkie dane powinny być postrzegane jako niezaufane albo potencjalnie groźne. Aplikacje które przetwarzają niezaufane dane wejściowe mogą stać się podatne na ataki takie jak Przepełnienie Buforu, SQL Injection, OS Commanding, Odmowa Usługi, a to zaledwie kilka z przykładów.

Jednych z kluczowych aspektów obsługiwania danych wejściowych jest weryfikacja czy dane spełniają określone kryteria. Do odpowiedniej weryfikacji, jest ważne aby zidentyfikować postać oraz typ danych, które są akceptowane i oczekiwane przez aplikację. Definiowanie oczekiwanego formatu i użytkowania każdej instancji niezaufanego wkładu jest wymagane do precyzyjnego zdefiniowania restrykcji. 

Weryfikacja może obejmować sprawdzenie typu rodzaju bezpieczeństwa i poprawnej składni. Wprowadzony ciąg może być sprawdzony pod względem długości(minimalna i maksymalna liczba znaków) i zestawu weryfikacji znaków podczas gdy typy danych liczbowych takie jak liczby całkowite i niecałkowite mogą być potwierdzone przeciwko potwierdzonych większych i mniejszych granic wartości. Kiedy łączysz dane wejściowe z kilku różnych źródeł, weryfikacja powinna być przeprowadzona podczas powiązania i nie tylko przeciwko indywidualnym elementom danych. Praktyka pomoże ominąć sytuacje gdzie weryfikacja danych wejściowych może się udać kiedy przeprowadzona na indywidualnych elementach danych nie powiodła się, kiedy jest zakończona kombinacja zestawu ze wszystkich źródeł.</desc>
	<solution>Faza: Architektura i Projektowanie

Używaj weryfikacji szkieletu danych wejściowych tak jak Struts lub OWASP ESAPI weryfikacja API.

Fazy: Architektura i Projektowanie; Implementacja
Zrozum wszystkie potencjalne obszary gdzie niezaufane dane wejściowe wejdą w twoje oprogramowanie: parametry lub argumenty, ciasteczka, jakikolwiek odczyt z sieci, zmiennych środowiskowych, wyszukiwania wstecznego DNS, wyniki zapytania, nagłówki żądań, komponenty URL, e-mail, pliki, bazy danych i dowolne zewnętrzne
systemy, które dostarczają dane do aplikacji. Pamiętaj o tym, że takie dane wejściowe mogą uzyskane poprzez wezwania API.

Dla kontroli bezpieczeństwa, która jest przeprowadzona po stronie klienta, upewnij się, że te kontrole są powielone po stronie serwera. Hakerzy mogą obejść kontrole po stronie klienta, modyfikując wartości po przeprowadzeniu kontroli lub zmieniając klienta, aby całkowicie usunąć kontrole po stronie klienta. Następnie te zmodyfikowane wartości zostaną przesłane do serwera.

Nawet jeśli kontrole po stronie klienta zapewniają minimalne korzyści z szacunkiem do zabezpieczeń po stronie serwera, są nadal przydatne. Po pierwsze, mogą wspierać detekcję intruzji. Jeśli serwer dostaje dane wejściowe, które powinny być odrzucone przez klienta, wtedy może to oznaczać wskazywanie ataku. Po drugie, błąd kontrolny po stronie klienta może zapewnić pomocne informacje zwrotne dla użytkownika, odnośnie oczekiwań dla prawidłowych danych wejściowych. Po trzecie, może zaistnieć redukcja przetwarzania czasu po stronie serwera dla przypadkowych błędów wejściowych jakkolwiek jest to typowe dla małych zapisów.

Do not rely exclusively on deny list validation to detect malicious input or to encode output. Istnieje za dużo sposobów do kodowania tego samego typu, więc prawdopodobnie ominiesz kilka wariantów.

Kiedy twoja aplikacja łączy dane z kilku źródeł, przeprowadź weryfikację po połączeniu tych źródeł. Indywidualne elementy danych mogą przejść część weryfikacyjną, ale mogą naruszyć zamierzone restrykcje po tym jak zostały połączone.

Zakładaj, że wszystkie dane wejściowe są szkodliwe. Use an "accept known good" input validation strategy, i.e., use an allow list of acceptable inputs that strictly conform to specifications. Odrzucaj wszystkie dane wejściowe, które nie są ściśle dopasowane ze specyfikacjami lub przeobraź je w takie, które są dopasowane. Do not rely exclusively on looking for malicious or malformed inputs (i.e., do not rely on a deny list). However, deny lists can be useful for detecting potential attacks or determining which inputs are so malformed that they should be rejected outright.

Kiedy przeprowadzasz weryfikację danych wejściowych, bierz pod uwagę wszystkie potencjalnie ważne właściwości, włączając długość, pełny zasięg akceptowalnych wartości, brakujących lub dodatkowych danych wejściowych, zgodność poprzez ważne pola i dostosowanie się do zasad sprawy. As an example of business rule logic, "boat" may be syntactically valid because it only contains alphanumeric characters, but it is not valid if you are expecting colors such as "red" or "blue."

Phase: Implementation

Be especially careful to validate your input when you invoke code that crosses language boundaries, such as from an interpreted language to native code. To może stworzyć nie przewidywalne interakcje pomiędzy granicami języka. Upewnij się, że nie naruszasz żadnych z zamierzeń języka, z którym współdziałasz. Na przykład, nawet jeśli Java może nie być podatna na przepełnienie bufora, podanie dużego argumentu w wywołaniu kodu natywnego może spowodować przepełnienie.

Bezpośrednio konwertuj twój typ danych wejściowych w przewidywany typ danych, tak jak używanie funkcji konwersji, która tłumaczy ciąg w liczbę. Po przekonwertowaniu na oczekiwany typ danych, upewnij się, że wartości danych wejściowych mieszczą się w podanym zakresie dostępnych wartości, oraz że wspólne wielo-dziedziny są utrzymywane.

Dane wejściowe powinny być dekodowane i kanonizowane do bieżącej wewnętrznej reprezentacji przed weryfikacją. Upewnij się, że twoja aplikacja nie zdekoduje nieumyślnie tych samych danych wejściowych dwa razy. Such errors could be used to bypass allow list schemes by introducing dangerous inputs after they have been checked. Używaj bibliotek takich jak kanoniczna kontrola OWASP ESAPI.

Rozważ przeprowadzenie powtarzanej kanonizacji dopóki twoje dane wejściowe już się nie zmienią. Pozwoli to uniknąć podwójnego dekodowania i podobnych scenariuszy, ale może nieumyślnie zmodyfikować dane wejściowe, które mogą zawierać poprawnie zakodowane niebezpieczne treści.

Podczas wymiany danych między komponentami upewnij się, że oba komponenty używają tego samego kodowania znaków. Upewnij się, że odpowiednie kodowanie jest stosowane w każdym interfejsie. Jawnie ustaw kodowanie, którego używasz, gdy tylko pozwala na to protokół.</solution>
	<reference>http://projects.webappsec.org/Improper-Input-Handling</reference>
	<reference>http://cwe.mitre.org/data/definitions/89.html</reference>
</vuln_item_wasc_20>

<vuln_items>wasc_21</vuln_items>
<vuln_item_wasc_21>
	<alert>Niewystarczająca Przeciw automatyzacja</alert>
	<desc>Niewystarczająca Przeciw automatyzacja pojawia się kiedy aplikacja webowa zezwala hakerowi zautomatyzować proces, który wpierw był zaprojektowany do przeprowadzenia tylko w sposób ręczny, n.p przez ludzkiego użytkownika strony.

Funkcjonalność aplikacji webowej, która jest często celem ataków automatyzacji, może obejmować:
    *Formularze loginów aplikacji-hakerzy mogą zautomatyzować metodą brutalnej siły żądania loginów usiłując zgadnąć dane logowania użytkownika
    *Formularze rejestracji serwisu-atakujący mogą automatycznie stworzyć tysiące nowych kont
    * Formularze e-mail - atakujący mogą wykorzystywać formularze e-mailowe jako przekaźniki spamu lub do zalewania skrzynek pocztowych niektórych użytkowników.
 *Utrzymanie konta- hakerzy mogą przeprowadzić zmasowany atak DoS przeciwko aplikacji poprzez zalanie jej licznymi żądaniami do wyłączenia lub usunięcia kont użytkowników
 *Formularze informacyjne konta- atakujący mogą przeprowadzić zmasowane próby zebrania personalnych danych użytkowników z aplikacji webowej
 *Formularze komentarzy/Składanie formularzy zawartości- może to być użyte do spamowania blogów, internetowych forach i internetowych tablic ogłoszeń poprzez automatyczne wnoszenie zawartości takiej jak spam lub nawet złośliwe oprogramowanie sieciowe
 *Formularze przywiązane do zapytań bazy danych SQL- mogą być one udostępnione w celu przeprowadzenia ataku odmowy serwisu przeciwko aplikacji. Atak jest przeprowadzany przez wysyłanie licznych ciężkich zapytań SQL w krótkim oddziale czasowym, stąd odrzucanie użytkowników przez serwis.
    *Zakupy internetowe/Handel elektroniczny- Aplikacje stron sklepów i handlu elektronicznego, które nie zmuszają tylko ludzkich klientów, mogą być wykorzystane w celu kupna preferowanych przedmiotów w ogromnych ilościach, takich jak bilety na wydarzenia sportowe. Później są one sprzedawane przez koniki za wyższe ceny.
    *Sondaże online- sondaże i inne typy systemów internetowego głosowania mogą być automatycznie skorumpowane na korzyść określonego wyboru.
    *Wysyłanie Wiadomości SMS oparte na sieci- atakujący mogą wykorzystać systemy wysyłające wiadomości SMS w celu spamowania telefonów użytkowników
	</desc>
	<solution>TBA</solution>
	<reference>http://projects.webappsec.org/Insufficient+Anti-automation</reference>
	<reference>http://cwe.mitre.org/data/definitions/116.html</reference>
</vuln_item_wasc_21>

<vuln_items>wasc_22</vuln_items>
<vuln_item_wasc_22>
	<alert>Niepoprawna Obsługa Danych Wyjściowych</alert>
	<desc>Obsługa danych wyjściowych nawiązuje do tego jak aplikacja generuje dane wychodzące.  Jeśli aplikacja posiada niepoprawną obsługę danych wyjściowych, dane te mogą być zużyte co prowadzi do zagrożenia bezpieczeństwa i nigdy nie zamierzonych akcji przez programistę aplikacji.  W wielu przypadkach, ta niezamierzona interpretacja jest klasyfikowana jako jedna z jednych form krytycznego zagrożenia bezpieczeństwa aplikacji.

Każda lokacja gdzie dane opuszczają granicę aplikacji mogą być zaliczane do niepoprawnej obsługi danych wyjściowych.  Granice aplikacji istnieją gdzie dane opuszczają jeden kontekst i przystępuje do innego.  This includes applications passing data to other applications via web services, sockets, command line, environmental variables, etc...  It also includes passing data between tiers within an application architecture, such as a database, directory server, HTML/JavaScript interpreter (browser), or operating system.  Więcej szczegółów na temat tego gdzie może się pojawić niepoprawna obsługa danych wyjściowych możesz znaleźć w sekcji poniżej zatytułowanej "Lokacje Powszechnych Danych Wyjściowych".

Niepoprawna obsługa danych wyjściowych może przyjmować różne formy w aplikacji.  Formy te mogą być kategoryzowane jako: błędy protokołu, błędy aplikacji i błędy zużycia zależnych danych.  Błędy protokołu obejmuję brakujące lub niepoprawne kodowanie wyjściowe lub pomijanie i przekazywanie złych danych.  Błędy aplikacji obejmują błędy logiczne takie jak przekazywane niepoprawnych danych lub przekazywanie szkodliwej zawartości niefiltrowanej.  Jeśli aplikacja nie odróżni poprawnie autentycznej zawartości od nieuprawnionej lub nie obejdzie znanych luk w zabezpieczeniach danych, może to spowodować nadużycie w korzystaniu z danych spowodowane niewłaściwą obsługą danych wyjściowych.

Aplikacja, która nie dostarcza danych we właściwym kontekście, może umożliwić osobie atakującej na nadużycie konsumenta danych.  Może to prowadzić do określonych zagrożeń wymienionych w Klasyfikacji zagrożeń WASC, takich jak fałszowanie zawartości, Cross-Site Scripting, dzielenie odpowiedzi HTTP, HTTP Response Smuggling, Wstrzyknięcie LDAP, polecenia OS, objazd Routingu, nadużywanie Soap Array, przekierowanie adresu URL, wstrzyknięcie XML, Wstrzyknięcie XQuery, Wstrzyknięcie XPath, Mail Command Injection, Null Injection i SQL Injection.

Właściwa obsługa danych wyjściowych zapobiega nieoczekiwanej lub niezamierzonej interpretacji danych przez konsumenta.  Do osiągniecie tego celu, deweloperzy muszą zrozumieć model danych aplikacji, jak dane będą konsumowane przez inne partie aplikacji i jak to będzie ostatecznie prezentowane użytkownikowi.  Techniki zapewnienia właściwej obsługi danych wyjściowych obejmują między innymi filtrowanie i sanityzacja danych (więcej szczegółów na temat sanityzacji i filtrowania danych wyjściowych można znaleźć w odpowiednio zatytułowanych sekcjach poniżej).  Natomiast, niekonsekwentne używanie wybranych technik obsługi danych wyjściowych mogą w rzeczywistości podnieść ryzyko niewłaściwej obsługi danych jeśli dane wejściowe są pominięte lub zostawione nieoczyszczone.  To zapewnienia "dogłębnej ochrony" deweloperzy muszą zakładać przy wyborze odpowiednich strategii obsługi wyjścia, że wszystkie dane w aplikacji są niezaufane.

Chociaż właściwa obsługa wyjścia może przybierać różne formy,, aplikacja nie może być bezpieczna dopóki nie ochrania przeciwko niezamierzonym interpretacjom przez konsumenta danych. Te kluczowe wymagania są niezbędne dla aplikacji do bezpiecznych operacji na danych wyjściowych.</desc>
	<solution>Używaj sprawdzonej biblioteki lub struktury, które nie pozwalają na wystąpienie tego osłabienia lub wprowadzają konstrukcje, które sprawiają, że to osłabienie jest łatwiejsze do uniknięcia.

Na przykład weź pod uwagę używanie kodowania kontrolnego ESAPI lub podobnych narzędzi, bibliotek lub struktur. Pomogą one programiście kodować wyjścia w sposób mniej podatny na błędy.

Alternatywnie, używaj wbudowanych funkcji, ale weź pod uwagę używanie wrapperów na wypadek, gdyby odkryto, że te funkcje są podatne.

Jeśli możliwe, używaj wymodelowane mechanizmy automatycznie wymuszające oddzielenie danych i kodu. Te mechanizmy mogą być w stanie zapewnić odpowiednie cytowanie, kodowanie i sprawdzanie poprawności automatycznie, zamiast polegać na programistach, aby zapewnić tę możliwość w każdym punkcie, w którym generowane są dane wyjściowe.

Na przykład przechowywane procedury mogą wymuszać strukturę zapytań bazy danych i zmniejszać prawdopodobieństwo iniekcji SQL.

Zapoznaj się z kontekstem, w którym będą używane twoje dane i kodowaniem, jakiego się spodziewasz. Jest to zwłaszcza ważne kiedy dane są transmitowane pomiędzy różnymi komponentami lub kiedy generowane są dane wyjściowe, które zawierają wielokrotne szyfrowanie w tym samym czasie, tak jak strony internetowe albo kilkuczęściowe wiadomości e-mail. Zbadaj wszystkie przewidywane protokoły komunikacyjne i reprezentacje danych, aby określić wymagane strategie kodowania.

W niektórych przypadkach, sprawdzanie poprawności danych wejściowych może być ważną strategią, gdy kodowanie wyjściowe nie jest zupełnym rozwiązaniem. Na przykład możesz dostarczyć te same dane wyjściowe, które będą przetwarzane przez wielu klientów używających różnych kodowań lub reprezentacji. W innych przypadkach może być wymagane zezwolenie, aby dane wejściowe dostarczone przez użytkownika zawierały informacje kontrolne, takie jak ograniczone znaczniki HTML, które obsługują formatowanie na wiki lub tablicy biuletynu. When this type of requirement must be met, use an extremely strict allow list to limit which control sequences can be used. Zweryfikuj czy skutkujące syntaktyczne struktury są takie jakie oczekujesz. Użyj standardowych metod kodowania dla pozostałej części danych wejściowych.

Użyj weryfikacji danych wejściowych jako środek dogłębnej obrony do redukowania prawdopodobieństwa błędów kodowania danych wyjściowych (zobacz CWE-20).

Podczas wymiany danych między komponentami upewnij się, że oba komponenty używają tego samego kodowania znaków. Upewnij się, że odpowiednie kodowanie jest stosowane w każdym interfejsie. Jawnie ustaw kodowanie, którego używasz, gdy tylko pozwala na to protokół.</solution>
	<reference>http://projects.webappsec.org/Improper-Output-Handling</reference>
	<reference/>
</vuln_item_wasc_22>

<vuln_items>wasc_23</vuln_items>
<vuln_item_wasc_23>
	<alert>Iniekcja XML</alert>
	<desc>Iniekcja XML jest techniką ataku używaną do manipulowania lub naruszenia logiki aplikacji lub usługi XML. Wstrzyknięcie niezamierzonej treści XML i / lub struktur do komunikatu XML może zmienić zamierzoną logikę aplikacji. Ponadto, iniekcja XML może spowodować wstawienie złośliwej treści do powstałej wiadomości / dokumentu.</desc>
	<solution>TBA</solution>
	<reference>http://projects.webappsec.org/XML-Injection</reference>
	<reference/>
</vuln_item_wasc_23>

<vuln_items>wasc_24</vuln_items>
<vuln_item_wasc_24>
	<alert>Rozdzielenie Żądania HTTP</alert>
	<desc>Rozdzielenie Żądania HTTP jest atakiem, który umożliwia zmuszenie przeglądarki do wysyłania dowolnych żądań HTTP, zadania XSS i zatruwania pamięci podręcznej przeglądarki. Istotą ataku jest zdolność atakującego, kiedy ofiara (przeglądarka) jest zmuszona załadować złośliwą stronę atakującego, aby manipulować jedną z funkcji przeglądarki w celu wysłania 2 żądań HTTP zamiast jednego żądania HTTP. Dwa takie mechanizmy były wykorzystywane do tej pory: obiekt XmlHttpRequest (skrót XHR) i skrót mechanizmu uwierzytelnienia HTTP. Aby ten atak zadziałał, przeglądarka musi używać serwera proxy HTTP (nie wszystkie z nich "obsługuje" ten atak) lub atak musi zostać przeprowadzony na hoście znajdującym się w tym samym IP (z punktu widzenia przeglądarki) co komputer hakera.</desc>
	<solution>Avoid using CRLF as a special sequence.

Appropriately filter or quote CRLF sequences in user-controlled input.</solution>
	<reference>http://projects.webappsec.org/HTTP-Request-Splitting</reference>
	<reference>http://cwe.mitre.org/data/definitions/93.html</reference>
</vuln_item_wasc_24>

<vuln_items>wasc_25</vuln_items>
<vuln_item_wasc_25>
	<alert>Podzielone Żądanie/Odpowiedź HTTP</alert>
	<desc>W ataku Podzielonego Żądania HTTP są zawsze zaangażowane 3 partie(przynajmniej):
    *Serwer sieci Web, który ma lukę bezpieczeństwa umożliwiającą Podzielenie Żądania HTTP.
    *Cel - jednostka, która wchodzi w interakcję z serwerem sieciowym w imieniu atakującego. Zwykle jest to bufor serwera z przednim/odwróconym proxy), lub przeglądarka (ewentualnie z pamięcią podręczną przeglądarki).
    * Atakujący - rozpoczyna atak

Istotą Podzielonego Żądania HTTP jest zdolność atakującego do wysłania pojedynczego żądania HTTP, które zmusza serwer WWW do utworzenia strumienia wyjściowego, który jest w normalnym przypadku interpretowany przez cel jako dwie odpowiedzi HTTP zamiast jednej. Pierwsza reakcja może być częściowo kontrolowana przez atakującego, ale jest to mniej ważne. Istotne jest to, że atakujący całkowicie kontroluje formę drugiej odpowiedzi z linii statusu HTTP do ostatniego bajtu treści odpowiedzi HTTP. Gdy jest to możliwe, atakujący realizuje atak wysyłając dwa żądania poprzez cel. Pierwsze wywołuje dwie odpowiedzi z serwera web, a drugie żądanie będzie zazwyczaj "niewinnym" źródłem na serwerze. Jednakże drugie żądanie będzie połączone przez cel z drugą odpowiedzią HTTP, która jest w pełni kontrolowana przez hakera. Zatem atakujący próbuje przekonać się, że określony zasób na serwerze sieciowym (oznaczony przez drugie żądanie) jest odpowiedzią serwera HTTP (zawartość serwera), podczas gdy w rzeczywistości jest to część danych, które zostały sfałszowane przez atakującego poprzez serwer internetowy - to jest druga odpowiedź.

Ataki Podzielonego żądania HTTP mają miejsce kiedy skrypt serwera utrwala dane użytkownika w nagłówkach odpowiedzi HTTP. Zazwyczaj dzieje się tak, gdy skrypt osadza dane użytkownika w adresie przekierowania odpowiedzi przekierowania (kod statusu HTTP 3xx) lub gdy skrypt osadza dane użytkownika w wartości cookie lub nazwie, gdy odpowiedź ustawia plik cookie.</desc>
	<solution>Twórz nagłówki HTTP bardzo ostrożnie, unikając użycia niezweryfikowanych danych wejściowych.</solution>
	<reference>http://projects.webappsec.org/HTTP-Response-Splitting</reference>
	<reference>http://cwe.mitre.org/data/definitions/113.html</reference>
</vuln_item_wasc_25>

<vuln_items>wasc_26</vuln_items>
<vuln_item_wasc_26>
	<alert>Przemycanie Żądania HTTP</alert>
	<desc>Przemycanie Żądania HTTP to technika ataku, która nadużywa rozbieżności w analizie żądań HTTP niezgodnych z RFC między dwoma urządzeniami HTTP (zazwyczaj frontowym serwerem proxy lub firewallem z obsługą HTTP i wewnętrznym serwerem WWW) w celu przemycenia żądania do drugiego urządzenie "przez" pierwsze urządzenie. Ta technika umożliwia atakującemu wysłanie jednego zestawu żądań do drugiego urządzenia, podczas gdy pierwsze urządzenie widzi inny zestaw żądań. To z kolei ułatwia kilka możliwych zastosowań, takich jak częściowe zatruwanie pamięci podręcznej, omijanie ochrony zapory i XSS.</desc>
	<solution>Użyj serwera WWW, który stosuje ścisłą procedurę analizy HTTP, taką jak Apache (zobacz artykuł w bibliografii).

Korzystaj tylko z komunikacji SSL.

Kończ sesję klienta po każdym żądaniu.

Zamień wszystkie strony na nie-cache'owalne.</solution>
	<reference>http://projects.webappsec.org/HTTP-Request-Smuggling</reference>
	<reference>http://cwe.mitre.org/data/definitions/444.html</reference>
</vuln_item_wasc_26>

<vuln_items>wasc_27</vuln_items>
<vuln_item_wasc_27>
	<alert>Przemycanie Odpowiedzi HTTP</alert>
	<desc>Przemycanie odpowiedzi HTTP jest techniką "przemycania" 2 odpowiedzi HTTP z serwera na klienta za pośrednictwem pośredniego urządzenia HTTP, które oczekuje (lub zezwala) na pojedynczą odpowiedź z serwera.

Jednym z zastosowań tej techniki jest ulepszenie podstawowej techniki dzielenia odpowiedzi HTTP w celu uniknięcia działań zapobiegających rozdzielaniu odpowiedzi HTTP. W takim przypadku pośrednik jest mechanizm zapobiegania podziału odpowiedzi HTTP między serwerem WWW a serwerem proxy (lub przeglądarką internetową). Innym przykładem użycia jest podszywanie się pod odpowiedzi otrzymane przez przeglądarkę. W tym przypadku złośliwa witryna internetowa wyświetla przeglądarce stronę, którą przeglądarka zinterpretuje jako pochodzącą z innej (docelowej) domeny. Przemycanie odpowiedzi HTTP może być użyte do tego, gdy przeglądarka korzysta z serwera proxy, aby uzyskać dostęp do obu stron.

Przemycanie odpowiedzi HTTP wykorzystuje techniki podobne do przemycania żądań HTTP, aby wykorzystać rozbieżności między tym, co mechanizm zapobiegania dzielenia odpowiedzi HTTP (lub serwer proxy) uznałby za strumień odpowiedzi HTTP, a strumień odpowiedzi jako analizowany przez serwer proxy (lub przeglądarkę). Tak więc, podczas gdy mechanizm zapobiegania dzielenia odpowiedzi HTTP może uznać dany strumień odpowiedzi za nieszkodliwy (pojedyncza odpowiedź HTTP), proxy / przeglądarka może nadal przetwarzać je jako dwie odpowiedzi HTTP, a zatem może być podatna na wszystkie wyniki pierwotnej techniki podziału odpowiedzi HTTP (w pierwszym przypadku użycia) lub może być podatna na podszywanie się (w drugim przypadku). Na przykład niektóre mechanizmy zapobiegania dzieleniu odpowiedzi HTTP używane przez niektóre silniki aplikacji zabraniają aplikacji wstawiania nagłówka zawierającego CR+LF do odpowiedzi. Jednak atakujący może zmusić aplikację do wstawienia nagłówka zawierającego CR, tym samym obchodząc mechanizm obronny. Niektóre serwery proxy nadal mogą traktować CR (tylko) jako separator nagłówka (i odpowiedzi), a zatem połączenie serwera internetowego i serwera proxy nadal będzie narażone na atak, który może zatruć pamięć podręczną proxy.
	</desc>
	<solution>TBA</solution>
	<reference>http://projects.webappsec.org/HTTP-Response-Smuggling</reference>
	<reference/>
</vuln_item_wasc_27>

<vuln_items>wasc_28</vuln_items>
<vuln_item_wasc_28>
	<alert>Wstrzyknięcie Bajtu Zerowego/Null</alert>
	<desc>Wstrzyknięcie Bajtu Null jest aktywną techniką wykorzystywaną do pomijania filtrów sprawdzających poprawność w infrastrukturze sieciowej poprzez dodawanie zakodowanych w postaci adresu URL znaków bajtów zerowych (tj.%00 lub 0x00 w hex) do danych dostarczanych przez użytkownika. Ten proces wstrzykiwania może zmienić zamierzoną logikę aplikacji i umożliwić złośliwemu przeciwnikowi uzyskanie nieautoryzowanego dostępu do plików systemowych.

Większość dzisiejszych aplikacji internetowych jest tworzona przy użyciu języków wyższego poziomu, takich jak PHP, ASP, Perl i Java. Jednak te aplikacje internetowe w pewnym momencie wymagają przetworzenia kodu wysokiego poziomu na poziomie systemu, a proces ten jest zwykle realizowany za pomocą funkcji "C / C ++". Zróżnicowana natura tych zależnych technologii zaowocowała klasą ataku nazywaną atakiem "Null Byte Injection" lub "Null Byte Poisoning". W C/C ++ bajt zerowy null reprezentuje punkt zakończenia łańcucha lub znak ogranicznika, co oznacza natychmiastowe przerwanie przetwarzania ciągu znaków. Bajty następujące po ograniczniku zostaną zignorowane. Jeśli łańcuch traci swój znak null, długość łańcucha staje się nieznana, dopóki wskaźnik pamięci nie osiągnie następnego bajtu zerowego. To niezamierzone rozgałęzienie może spowodować nietypowe zachowanie i wprowadzić luki w systemie lub zasięgu aplikacji. W podobny sposób kilka języków wyższego poziomu traktuje "bajt zerowy" jako symbol zastępczy dla długości łańcucha znaków, ponieważ nie ma on specjalnego znaczenia w ich kontekście. Ze względu na tę różnicę w interpretacji można łatwo wprowadzić puste bajty, aby manipulować zachowaniem aplikacji.

Adresy URL są ograniczone do zestawu znaków US-ASCII w zakresie od 0x20 do 0x7E (hex) lub od 32 do 126 (dziesiętnie). Jednak wspomniany zakres używa kilku znaków, które nie są dozwolone, ponieważ mają specjalne znaczenie w kontekście protokołu HTTP. Z tego powodu schemat kodowania adresów URL został wprowadzony w celu uwzględnienia znaków specjalnych w adresie URL przy użyciu rozszerzonej reprezentacji znaków ASCII. W kontekście "bajtu zerowego" jest to reprezentowane jako%00 w systemie szesnastkowym. Zakres ataku bajtu zerowego rozpoczyna się, gdy aplikacje internetowe wchodzą w interakcję z aktywnymi procedurami "C" i zewnętrznymi interfejsami API z bazowego systemu operacyjnego. Pozwala to atakującemu na manipulowanie zasobami sieciowymi poprzez czytanie lub zapisywanie plików na podstawie uprawnień użytkownika aplikacji.</desc>
	<solution>Programiści powinni przewidywać, że znaki puste lub bajty zerowe będą wstrzykiwane / usuwane / manipulowane w wektorach wejściowych ich oprogramowania. Użyj odpowiedniej kombinacji czarnych list i białych list, aby zapewnić, że system przetwarza tylko prawidłowe, oczekiwane i odpowiednie dane wejściowe.

Zakładaj, że wszystkie dane wejściowe są szkodliwe. Użyj standardowego mechanizmu sprawdzania poprawności danych wejściowych, aby sprawdzić wszystkie dane wejściowe dotyczące długości, typu, składni i reguł biznesowych przed zaakceptowaniem danych do wyświetlenia lub zapisania. Użyj strategii sprawdzania poprawności "zaakceptuj znany dobry".

Użyj i określ silne kodowanie wyjściowe (takie jak ISO 8859-1 lub UTF 8).

Do not rely exclusively on deny list validation to detect malicious input or to encode output. Istnieje zbyt wiele wariantów kodowania znaków; prawdopodobnie przegapisz kilka wariantów.

Dane wejściowe powinny być dekodowane i kanonizowane do bieżącej wewnętrznej reprezentacji przed weryfikacją. Upewnij się, że twoja aplikacja nie dekoduje tego samego wejścia dwukrotnie. Such errors could be used to bypass allow list schemes by introducing dangerous inputs after they have been checked.</solution>
	<reference>http://projects.webappsec.org/Null-Byte-Injection</reference>
	<reference>http://cwe.mitre.org/data/definitions/158.html</reference>
</vuln_item_wasc_28>

<vuln_items>wasc_29</vuln_items>
<vuln_item_wasc_29>
	<alert>LDAP Injection</alert>
	<desc>Wtryskiwanie LDAP jest techniką ataku wykorzystywaną do korzystania ze stron internetowych, które konstruują instrukcje LDAP z danych wprowadzonych przez użytkownika.

Protokół LDAP (Lightweight Directory Access Protocol) to otwarty protokół do obsługi zapytań i manipulowania usługami katalogowymi X.500. Protokół LDAP działa na protokołach transportowych internetu, takich jak TCP. Aplikacje internetowe mogą wykorzystywać dane wprowadzane przez użytkownika do tworzenia niestandardowych instrukcji LDAP dla dynamicznych żądań stron WWW.

Gdy aplikacja internetowa nie może właściwie weryfikować danych wprowadzonych przez użytkownika, osoba atakująca może zmienić konstrukcję instrukcji LDAP. Gdy osoba atakująca może zmodyfikować instrukcję LDAP, proces zostanie uruchomiony z tymi samymi uprawnieniami, co składnik, który wykonał polecenie. (np. serwer bazy danych, serwer aplikacji www, serwer www itp.). Może to spowodować poważne problemy z bezpieczeństwem, gdy uprawnienia dają prawa do wysyłania zapytań, modyfikowania lub usuwania czegokolwiek w drzewie LDAP. Te same zaawansowane techniki eksploracji dostępne we Wstrzykiwaniu SQL mogą być podobnie stosowane we Wstrzykiwaniu LDAP.</desc>
	<solution>Zakładaj, że wszystkie dane wejściowe są szkodliwe. Use an appropriate combination of black lists and white lists to neutralize LDAP syntax from user-controlled input.</solution>
	<reference>http://projects.webappsec.org/LDAP-Injection</reference>
	<reference>http://cwe.mitre.org/data/definitions/90.html</reference>
</vuln_item_wasc_29>

<vuln_items>wasc_30</vuln_items>
<vuln_item_wasc_30>
	<alert>Wstrzykiwanie Poleceń Mail</alert>
	<desc>Wstrzykiwanie Poleceń Mail to technika ataku używana do wykorzystywania serwerów pocztowych i aplikacji poczty internetowej, które konstruują instrukcje IMAP / SMTP z danych wprowadzonych przez użytkownika, które nie zostały odpowiednio zweryfikowane. W zależności od rodzaju instrukcji wykorzystanej przez atakującego, spotykamy dwa rodzaje wstrzyknięć: IMAP i SMTP. Wstrzykiwanie IMAP / SMTP może umożliwić dostęp do serwera pocztowego, do którego wcześniej nie miałeś dostępu. W niektórych przypadkach te wewnętrzne systemy nie mają takiego samego poziomu zabezpieczeń infrastruktury, jak w przypadku większości serwerów WWW typu front-end. Stąd, atakujący może stwierdzić, że serwer pocztowy daje lepsze rezultaty w zakresie eksploatacji. Z drugiej strony ta technika pozwala uniknąć możliwych ograniczeń, które mogą istnieć na poziomie aplikacji (CAPTCHA, maksymalna liczba żądań itd.).</desc>
	<solution>Zrozum wszystkie potencjalne obszary, w których niezaufane dane wejściowe mogą wejść do twojego oprogramowania: parametry lub argumenty, pliki cookie, wszystko, co czytasz z sieci, zmienne środowiskowe, nagłówki żądań, a także zawartość, składniki URL, e-mail, pliki, bazy danych i wszelkie systemy zewnętrzne które dostarczają dane do aplikacji. Wykonaj sprawdzanie danych wejściowych na dobrze zdefiniowanych interfejsach.

Zakładaj, że wszystkie dane wejściowe są szkodliwe. Use an "accept known good" input validation strategy (i.e., use an allow list). Odrzucaj wszystkie dane wejściowe, które nie są ściśle dopasowane ze specyfikacjami lub przeobraź je w takie, które są dopasowane. Use a deny list to reject any unexpected inputs and detect potential attacks.

Do not rely exclusively on deny list validation to detect malicious input or to encode output. Istnieje za dużo sposobów do kodowania tego samego typu, więc prawdopodobnie ominiesz kilka wariantów.

Bezpośrednio konwertuj twój typ danych wejściowych w przewidywany typ danych, tak jak używanie funkcji konwersji, która tłumaczy ciąg w liczbę. Po przekonwertowaniu na oczekiwany typ danych, upewnij się, że wartości danych wejściowych mieszczą się w podanym zakresie dostępnych wartości, oraz że wspólne wielo-dziedziny są utrzymywane.

Dane wejściowe powinny być dekodowane i kanonizowane do bieżącej wewnętrznej reprezentacji przed weryfikacją. Upewnij się, że aplikacja dwukrotnie nie odkodowuje tego samego wejścia. Such errors could be used to bypass allow list schemes by introducing dangerous inputs after they have been checked. Używaj bibliotek takich jak kanoniczna kontrola OWASP ESAPI.

Rozważ przeprowadzenie powtarzanej kanonizacji dopóki twoje dane wejściowe już się nie zmienią. Pozwoli to uniknąć podwójnego dekodowania i podobnych scenariuszy, ale może nieumyślnie zmodyfikować dane wejściowe, które mogą zawierać poprawnie zakodowane niebezpieczne treści.

Podczas wymiany danych między komponentami upewnij się, że oba komponenty używają tego samego kodowania znaków. Upewnij się, że odpowiednie kodowanie jest stosowane w każdym interfejsie. Jawnie ustaw kodowanie, którego używasz, gdy tylko pozwala na to protokół.

Kiedy twoja aplikacja łączy dane z kilku źródeł, przeprowadź weryfikację po połączeniu tych źródeł. Indywidualne elementy danych mogą przejść część weryfikacyjną, ale mogą naruszyć zamierzone restrykcje po tym jak zostały połączone.</solution>
	<reference>http://projects.webappsec.org/Mail-Command-Injection</reference>
	<reference>http://cwe.mitre.org/data/definitions/88.html</reference>
</vuln_item_wasc_30>

<vuln_items>wasc_31</vuln_items>
<vuln_item_wasc_31>
	<alert>Sterowanie OS</alert>
	<desc>Sterowanie OS jest techniką ataku używaną do nieautoryzowanego wykonywania poleceń systemu operacyjnego.

Sterowanie OS tj. systemem operacyjnym jest bezpośrednim wynikiem mieszania zaufanego kodu i niezaufanych danych. Atak ten jest możliwy, gdy aplikacja akceptuje niezaufane dane wejściowe do budowania poleceń systemu operacyjnego w sposób niezabezpieczony, obejmujący niewłaściwe czyszczenie danych i / lub nieprawidłowe wywoływanie programów zewnętrznych. W ataku sterującym systemem operacyjnym polecenia wykonywane przez atakującego będą działać z tymi samymi uprawnieniami, co składnik, który wykonał polecenie (np. Serwer bazy danych, serwer aplikacji WWW, serwer WWW, funkcje opakowujące, aplikacja). Ponieważ polecenia są wykonywane z uprawnieniami składnika wykonującego, atakujący może je wykorzystać w celu uzyskania dostępu lub uszkodzenia części, które w innym przypadku są nieosiągalne (na przykład katalogi i pliki systemu operacyjnego).</desc>
	<solution>Jeśli to możliwe, użyj wywołań bibliotek, a nie procesów zewnętrznych, aby odtworzyć pożądaną funkcjonalność.

Uruchom swój kod w środowisku "więzienia" lub podobnym środowisku piaskownicy, które wymusza ścisłe granice między procesem a systemem operacyjnym. Może to skutecznie ograniczyć, które pliki mogą być dostępne w określonym katalogu lub które polecenia mogą być wykonywane przez twoje oprogramowanie.

Przykłady poziomu OS obejmujące Unix chroot jail, AppArmor, and SELinux. Na zasadach ogólnych, zarządzany kod może zapewnić pewną ochronę. Na przykład,, java.io.FilePermission w Menadżerze Ochrony Javy umożliwia ci sprecyzować ograniczenia odnośnie operacji na plikach.
To może nie być wykonalne rozwiązanie i ogranicza wpływ tylko na system operacyjny; reszta aplikacji może wciąż być podatna na zagrożenie.

W przypadku danych, które zostaną użyte do wygenerowania polecenia do wykonania, należy zachować jak najwięcej danych poza kontrolą zewnętrzną. Na przykład w aplikacjach internetowych może to wymagać przechowywania polecenia lokalnie w stanie sesji zamiast wysyłania go do klienta w ukrytym polu formularza.

Używaj sprawdzonej biblioteki lub struktury, które nie pozwalają na wystąpienie tego osłabienia lub wprowadzają konstrukcje, które sprawiają, że to osłabienie jest łatwiejsze do uniknięcia.

Na przykład weź pod uwagę używanie kodowania kontrolnego ESAPI lub podobnych narzędzi, bibliotek lub struktur. Pomogą one programiście kodować wyjścia w sposób mniej podatny na błędy.

Jeśli chcesz używać generowanych dynamicznie ciągów lub poleceń zapytania, pomimo ryzyka, poprawnie cytuj argumenty i unikaj znaków specjalnych w obrębie tych argumentów. The most conservative approach is to escape or filter all characters that do not pass an extremely strict allow list (such as everything that is not alphanumeric or white space). Jeśli kilka specjalnych znaków jest potrzebnych, takie jak znak kontrolny, opakuj każdy argumenty w cytat zaraz po kroku unikania/filtrowania. Uważaj na wstrzyknięcie argumentu.

Jeśli program do wykonania pozwala na podanie argumentów w pliku wejściowym lub ze standardowego wejścia, należy rozważyć użycie tego trybu do przekazania argumentów zamiast wiersza poleceń.

Jeśli możliwe, używaj wymodelowane mechanizmy automatycznie wymuszające oddzielenie danych i kodu. Te mechanizmy mogą być w stanie zapewnić odpowiednie cytowanie, kodowanie i sprawdzanie poprawności automatycznie, zamiast polegać na programistach, aby zapewnić tę możliwość w każdym punkcie, w którym generowane są dane wyjściowe.

Niektóre języki oferują wiele funkcji, których można użyć do wywoływania poleceń. Jeśli jest to możliwe, należy zidentyfikować dowolną funkcję, która wywołuje powłokę poleceń za pomocą pojedynczego ciągu znaków i zastąpić ją funkcją wymagającą indywidualnych argumentów. Te funkcje zazwyczaj wykonują odpowiednie cytowanie i filtrowanie argumentów. Na przykład w C funkcja system() akceptuje łańcuch zawierający całe polecenie do wykonania, podczas gdy execl(), execve() i inne wymagają tablicy łańcuchów, po jednym dla każdego argumentu. W systemie Windows CreateProcess() przyjmuje tylko jedno polecenie naraz. W Perlu, jeśli polecenie system() jest zasilone tablicą argumentów, wówczas wywoła każdy z argumentów.

Zakładaj, że wszystkie dane wejściowe są szkodliwe. Use an "accept known good" input validation strategy, i.e., use an allow list of acceptable inputs that strictly conform to specifications. Odrzucaj wszystkie dane wejściowe, które nie są ściśle dopasowane ze specyfikacjami lub przeobraź je w takie, które są dopasowane. Do not rely exclusively on looking for malicious or malformed inputs (i.e., do not rely on a deny list). However, deny lists can be useful for detecting potential attacks or determining which inputs are so malformed that they should be rejected outright.

Kiedy przeprowadzasz weryfikację danych wejściowych, bierz pod uwagę wszystkie potencjalnie ważne właściwości, włączając długość, pełny zasięg akceptowalnych wartości, brakujących lub dodatkowych danych wejściowych, zgodność poprzez ważne pola i dostosowanie się do zasad sprawy. As an example of business rule logic, "boat" may be syntactically valid because it only contains alphanumeric characters, but it is not valid if you are expecting colors such as "red" or "blue."

When constructing OS command strings, use stringent allow lists that limit the character set based on the expected value of the parameter in the request. To bezpośrednio ograniczy zakres ataku, jednakże ta technika jest mniej ważna niż poprawne kodowanie i unikanie danych wyjściowych.

Zauważ, że odpowiednie kodowanie wyjściowe, unikanie i cytowanie jest najskuteczniejszym rozwiązaniem zapobiegającym iniekcji poleceń systemu operacyjnego, chociaż sprawdzanie poprawności danych wejściowych może zapewnić pewną obronę. Dzieje się tak, ponieważ skutecznie ogranicza to, co pojawi się w danych wyjściowych. Sprawdzanie poprawności danych wejściowych nie zawsze zapobiega iniekcji poleceń systemu operacyjnego, szczególnie jeśli wymagane jest obsługiwanie dowolnych pól tekstowych, które mogą zawierać dowolne znaki. Na przykład podczas wywoływania programu pocztowego może być konieczne zezwolenie, aby pole tematu zawierało inaczej - niebezpieczne dane wejściowe, takie jak ";" oraz znaki ">", które powinny zostać usunięte lub w inny sposób obsługiwane. Na przykład podczas wywoływania programu pocztowego może być konieczne zezwolenie, aby pole tematu zawierało inaczej - niebezpieczne dane wejściowe, takie jak ";" oraz znaki ">", które powinny zostać usunięte lub w inny sposób obsługiwane. Może to wydawać się drobną niedogodnością, ale może być ważniejsze, gdy program opiera się na dobrze uporządkowanych liniach tematycznych, aby przekazywać wiadomości do innych komponentów.

Nawet jeśli popełnisz błąd podczas sprawdzania poprawności (np. zapomnisz jednego ze 100 pól wejściowych), odpowiednie kodowanie prawdopodobnie ochroni Cię przed atakami opartymi na wstrzykiwaniu. Tak długo, jak nie jest to robione w odizolowaniu, walidacja danych wejściowych jest wciąż użyteczną techniką, ponieważ może znacznie zmniejszyć powierzchnię ataku, umożliwić wykrycie niektórych ataków i zapewnić inne korzyści bezpieczeństwa, których właściwe kodowanie nie rozwiązuje.</solution>
	<reference>http://projects.webappsec.org/OS-Commanding</reference>
	<reference>http://cwe.mitre.org/data/definitions/78.html</reference>
</vuln_item_wasc_31>

<vuln_items>wasc_32</vuln_items>
<vuln_item_wasc_32>
	<alert>Omijanie Routingu</alert>
	<desc>Protokół WS-Routing to protokół wymiany wiadomości SOAP od początkowego nadawcy wiadomości do ostatecznego odbiorcy, zwykle za pośrednictwem zestawu pośredników. Protokół WS-Routing jest zaimplementowany jako rozszerzenie SOAP i jest osadzony w nagłówku SOAP. WS-Routing jest często wykorzystywany do zapewniania sposobu kierowania ruchu XML przez złożone środowiska i transakcje, umożliwiając tymczasowym stacjom w ścieżce XML przypisywanie instrukcji routingu do dokumentu XML.

Omijanie Routingu jest rodzajem ataku "Man in the Middle", w którym pośrednicy mogą zostać wstrzyknięci lub "przejęci" w celu kierowania wrażliwych wiadomości na zewnątrz. Informacje o routingu (w nagłówku HTTP lub w nagłówku WS-Routing) można modyfikować na trasie, a ślady trasowania można usunąć z nagłówka i komunikatów, tak że aplikacja odbierająca nie ma żadnego pojęcia, że nastąpiło ominięcie routingu. Nagłówek i wstawianie obiektów nagłówków jest często mniej chronione niż wiadomość; wynika to z faktu, że nagłówek jest używany jako uchwyt dla metadanych dotyczących transakcji, takich jak uwierzytelnianie, routing, formatowanie, schemat, kanonizacja, przestrzenie nazw itp. Ponadto wiele procesów może być zaangażowanych w dodawanie / przetwarzanie nagłówka dokumentu XML. W wielu implementacjach informacje o routingu mogą pochodzić z zewnętrznej usługi WWW (na przykład przy użyciu polecenia WS-Referral), która zapewnia określone trasowanie dla transakcji.

WS-Addressing to nowszy standard opublikowany przez W3C w celu zapewnienia funkcji routingu dla komunikatów SOAP. Jedną z kluczowych różnic między WS-Routing i WS-Addressing jest to, że WS-Addressing zapewnia tylko następną lokalizację na trasie. Chociaż dokonano niewielu badań nad podatnością WS-Adressing na atak omijania, przynajmniej jeden artykuł (patrz odnośnik # 6 poniżej) sugeruje, że WS-Adressing jest również narażone na omijanie routingu.</desc>
	<solution>Zawsze w pełni uwierzytelniaj obie strony dowolnego kanału komunikacyjnego.

Przestrzegaj zasady pełnej mediacji.

Certyfikat wiąże tożsamość z kluczem kryptograficznym w celu uwierzytelnienia strony przekazującej. Często certyfikat pobiera zaszyfrowaną formę hasha tożsamości podmiotu, klucza publicznego i informacji, takich jak czas wydania lub wygaśnięcia, przy użyciu klucza prywatnego wystawcy. Certyfikat można sprawdzić, odczytując certyfikat za pomocą klucza publicznego wystawcy. Zobacz także łańcuchy podpisów certyfikatów X.509 i strukturę certyfikacji PGP.</solution>
	<reference>http://projects.webappsec.org/Routing-Detour</reference>
	<reference>http://cwe.mitre.org/data/definitions/300.html</reference>
</vuln_item_wasc_32>

<vuln_items>wasc_33</vuln_items>
<vuln_item_wasc_33>
	<alert>Obchodzenie Ścieżki</alert>
	<desc>Technika ataku Obchodzenie Ścieżki / Path Traversal umożliwia atakującemu dostęp do plików, katalogów i poleceń, które potencjalnie znajdują się poza głównym katalogiem dokumentów internetowych. Osoba atakująca może manipulować adresem URL w taki sposób, że strona internetowa będzie wykonywać lub ujawniać zawartość dowolnych plików w dowolnym miejscu na serwerze sieciowym. Każde urządzenie, które udostępnia interfejs oparty na HTTP, jest potencjalnie narażone na działanie ataku Path Traversal.

Większość witryn internetowych ogranicza dostęp użytkownika do określonej części systemu plików, zwykle nazywanej katalogiem "katalog główny dokumentu sieciowego" lub "katalog główny CGI". Katalogi te zawierają pliki przeznaczone do uzyskiwania dostępu przez użytkownika oraz plik wykonywalny niezbędny do sterowania funkcjami aplikacji internetowych. Aby uzyskać dostęp do plików lub wykonywać polecenia w dowolnym miejscu systemu plików, ataki Obchodzenia Ścieżki będą wykorzystywać cechy sekwencji znaków specjalnych.

Najbardziej podstawowy atak Obchodzenia Ścieżki wykorzystuje sekwencję znaków specjalnych "../" w celu zmiany żądanej lokalizacji zasobu w adresie URL. Chociaż najpopularniejsze serwery internetowe zapobiegną wyjściu z głównego katalogu dokumentów internetowych, alternatywne kodowanie sekwencji "../" może pomóc ominąć filtry bezpieczeństwa. Te odmiany metod zawierają poprawne i niepoprawne kodowanie Unicode ("..%u2216" lub "..%c0%af") znaku ukośnika, znaków ukośnika odwrotnego ("..\") na serwerach Windows, zakodowanych w adresach URL znaki "%2e%2e%2f") i podwójne kodowanie URL ("..%255c") znaku ukośnika odwrotnego.

Nawet jeśli serwer sieciowy właściwie ograniczy próby Obejścia Ścieżki w ścieżce adresu URL, sama aplikacja internetowa może nadal być podatna z powodu niewłaściwej obsługi danych wprowadzanych przez użytkownika. Jest to powszechny problem aplikacji internetowych, które korzystają z mechanizmów szablonów lub ładują tekst statyczny z plików. W odmianach tego ataku, oryginalna wartość parametru adresu URL jest zastępowana nazwą pliku jednego ze skryptów dynamicznych aplikacji WWW. W rezultacie wyniki mogą ujawnić kod źródłowy, ponieważ plik jest interpretowany jako tekst, a nie skrypt wykonywalny. These techniques often employ additional special characters such as the dot (".") to reveal the listing of the current working directory, or "%00" NULL characters in order to bypass rudimentary file extension checks.</desc>
	<solution>Zakładaj, że wszystkie dane wejściowe są szkodliwe. Use an "accept known good" input validation strategy, i.e., use an allow list of acceptable inputs that strictly conform to specifications. Odrzucaj wszystkie dane wejściowe, które nie są ściśle dopasowane ze specyfikacjami lub przeobraź je w takie, które są dopasowane. Do not rely exclusively on looking for malicious or malformed inputs (i.e., do not rely on a deny list). However, deny lists can be useful for detecting potential attacks or determining which inputs are so malformed that they should be rejected outright.

Kiedy przeprowadzasz weryfikację danych wejściowych, bierz pod uwagę wszystkie potencjalnie ważne właściwości, włączając długość, pełny zasięg akceptowalnych wartości, brakujących lub dodatkowych danych wejściowych, zgodność poprzez ważne pola i dostosowanie się do zasad sprawy. As an example of business rule logic, "boat" may be syntactically valid because it only contains alphanumeric characters, but it is not valid if you are expecting colors such as "red" or "blue."

For filenames, use stringent allow lists that limit the character set to be used. Jeśli to możliwe, zezwól tylko na pojedynczy "." znak w nazwie pliku, aby uniknąć słabości i wykluczyć separatory katalogów, takie jak "/". Use an allow list of allowable file extensions.

Uwaga jeśli próbujesz oczyścić dane, zrób tak, aby efekt końcowy nie był w formie, która może być niebezpieczna. Mechanizm dezynfekcji może usuwać znaki takie jak "." i ';' , które mogą być wymagane w przypadku niektórych podatności. Osoba atakująca może próbować oszukać mechanizm czyszczący w celu "oczyszczenia" danych do niebezpiecznej formy. Załóżmy, że atakujący wstrzykuje "." wewnątrz nazwy pliku (np. "sensi.tiveFile") i mechanizm sanityzacji usuwa znak, który daje prawidłową nazwę pliku "sensitiveFile". Jeśli dane wejściowe zostaną teraz uznane za bezpieczne, plik może zostać naruszony. 

Dane wejściowe powinny być dekodowane i kanonizowane do bieżącej wewnętrznej reprezentacji przed weryfikacją. Upewnij się, że twoja aplikacja nie dekoduje tego samego wejścia dwukrotnie. Such errors could be used to bypass allow list schemes by introducing dangerous inputs after they have been checked.

Użyj wbudowanej funkcji kanonizacji ścieżki (takiej jak realpath() w C), która produkuje kanoniczną wersję nazwy ścieżki, która skutecznie usuwa sekwencje ".." i dowiązania symboliczne.

Uruchom swój kod używając najmniejszych przywilejów, które są wymagane do wykonania koniecznych zadań. Jeśli możliwe, utwórz odizolowane konta z limitowanymi przywilejami, które są używane tylko do pojedynczych zadań. Tą drogą, skuteczny atak nie da gwałtownie dostępu do reszty oprogramowania lub jego środowiska. Na przykład, baza danych aplikacji rzadko musi uruchomić bazę danych administratora zwłaszcza w codziennych operacjach.

Kiedy zbiór akceptowalnych obiektów, takich jak nazwy plików lub adresy URL, jest ograniczony lub znany, utwórz odwzorowanie ze zbioru stałych wartości wejściowych (takich jak identyfikatory numeryczne) do rzeczywistych nazw plików lub adresów URL i odrzuć wszystkie inne dane wejściowe.

Uruchom swój kod w środowisku "więzienia" lub podobnym środowisku piaskownicy, które wymusza ścisłe granice między procesem a systemem operacyjnym. Może to skutecznie ograniczyć, które pliki mogą być dostępne w określonym katalogu lub które polecenia mogą być wykonywane przez twoje oprogramowanie.

Przykłady poziomu OS obejmujące Unix chroot jail, AppArmor, and SELinux. Na zasadach ogólnych, zarządzany kod może zapewnić pewną ochronę. Na przykład,, java.io.FilePermission w Menadżerze Ochrony Javy umożliwia ci sprecyzować ograniczenia odnośnie operacji na plikach.

To może nie być wykonalne rozwiązanie i ogranicza wpływ tylko na system operacyjny; reszta aplikacji może wciąż być podatna na zagrożenie.
</solution>
	<reference>http://projects.webappsec.org/Path-Traversal</reference>
	<reference>http://cwe.mitre.org/data/definitions/22.html</reference>
</vuln_item_wasc_33>

<vuln_items>wasc_34</vuln_items>
<vuln_item_wasc_34>
	<alert>Przewidywalna Lokalizacja Zasobów</alert>
	<desc>Przewidywalna Lokalizacja Zasobów to technika ataku używana do odkrywania ukrytej zawartości i funkcjonalności witryny. Poprzez sprytne zgadywanie i 'brute forcing' atakujący może odgadnąć nazwy plików i katalogów nieprzeznaczonych do publicznego oglądania. Brut forcing nazw plików jest łatwe, ponieważ pliki / ścieżki często mają wspólną konwencję nazewnictwa i znajdują się w standardowych lokalizacjach. Mogą to być pliki tymczasowe, pliki kopii zapasowych, dzienniki, sekcje witryny administracyjnej, pliki konfiguracyjne, aplikacje demonstracyjne i przykładowe pliki. Pliki te mogą ujawniać poufne informacje na temat strony internetowej, wewnętrznych aplikacji internetowych, informacji o bazie danych, haseł, nazw maszyn, ścieżek plików do innych wrażliwych obszarów itp.

Pomoże to nie tylko zidentyfikować obszar witryny, co może doprowadzić do odkrycia dodatkowych luk w witrynie, ale może również ujawnić atakującemu poufne informacje dotyczące środowiska lub użytkowników. Przewidywanie Lokalizacja Zasobu jest również znane jako Wymuszone Przeglądanie, Wyliczanie Plików i Wyliczanie Katalogów.</desc>
	<solution>Apply appropriate access control authorizations for each access to all restricted URLs, scripts or files.

Consider using MVC based frameworks such as Struts.</solution>
	<reference>http://projects.webappsec.org/Predictable-Resource-Location</reference>
	<reference>http://cwe.mitre.org/data/definitions/425.html</reference>
</vuln_item_wasc_34>

<vuln_items>wasc_35</vuln_items>
<vuln_item_wasc_35>
	<alert>Nadużycie Tablicy SOAP</alert>
	<desc>Tablice XML SOAP są częstym celem złośliwych nadużyć. Tablice SOAP są zdefiniowane jako posiadające typ "SOAP-ENC: Array" lub typ pochodzący z niego. Tablice SOAP mają jeden lub więcej wymiarów (rangę), których elementy są rozróżniane przez pozycję porządkową. Wartość tablicowa jest reprezentowana jako szereg elementów odzwierciedlających tablicę, a elementy pojawiają się w rosnącej kolejności porządkowej. W przypadku wielowymiarowych tablic wymiar po prawej stronie zmienia się najszybciej. Każdy element składowy jest nazywany jako niezależny element. Usługa WWW, która oczekuje, że tablica może być celem ataku XML DoS, zmusza serwer SOAP do zbudowania olbrzymiej tablicy w pamięci urządzenia, powodując w ten sposób warunek DoS na maszynie ze względu na wstępną alokację pamięci.</desc>
	<solution> Wykonaj odpowiednią weryfikację danych wejściowych względem dowolnej wartości, która wpływa na ilość przydzielonej pamięci. Zdefiniuj odpowiednią strategię obsługi żądań przekraczających limit i rozważ obsługę opcji konfiguracji, aby administrator mógł zwiększyć ilość pamięci, która będzie używana, jeśli to konieczne.

Uruchom swój program, korzystając z limitów zasobów dostarczanych przez system dla pamięci. Może to nadal spowodować awarię programu lub wyjście, ale wpływ na resztę systemu zostanie zminimalizowany.</solution>
	<reference>http://projects.webappsec.org/SOAP-Array-Abuse</reference>
	<reference>http://cwe.mitre.org/data/definitions/789.html</reference>
</vuln_item_wasc_35>

<vuln_items>wasc_36</vuln_items>
<vuln_item_wasc_36>
	<alert>Wstrzyknięcie SSI</alert>
	<desc>Wstrzyknięcie SSI (Server-side Include) to technika wykorzystywana po stronie serwera, która umożliwia atakującemu wysłanie kodu do aplikacji internetowej, która później zostanie wykonana lokalnie przez serwer sieciowy. Wstrzykiwanie SSI wykorzystuje niezdolność aplikacji internetowej do oczyszczenia danych dostarczonych przez użytkownika, zanim zostaną one wstawione do pliku HTML interpretowanego po stronie serwera.

Przed udostępnieniem strony internetowej HTML serwer sieci Web może analizować i wykonywać instrukcje dołączania po stronie serwera przed przekazaniem jej klientowi. W niektórych przypadkach (np. tablice ogłoszeń, księgi gości lub systemy zarządzania treścią) aplikacja internetowa wstawi dostarczone przez użytkownika dane do źródła strony internetowej.

Jeśli osoba atakująca prześle instrukcje do wykonania po stronie serwera, może mieć możliwość wykonywania dowolnych poleceń systemu operacyjnego lub dołączyć ukrytą zawartość pliku przy następnym wyświetleniu strony. Jest to wykonywane na poziomie uprawnień użytkownika serwera WWW.</desc>
	<solution>Wyłącz wykonywanie SSI na stronach, które go nie wymagają. Dla stron wymagających SSI upewnij się, że wykonałeś następujące sprawdzenia
- Włącz tylko dyrektywy SSI, które są potrzebne dla tej strony i wyłącz wszystkie pozostałe.
- encja HTML koduje dane dostarczone przez użytkownika przed przekazaniem ich do strony z uprawnieniami do wykonywania SSI.
- Użyj SUExec, aby strona była wykonywana jako właściciel pliku, a nie użytkownik serwera WWW.</solution>
	<reference>http://projects.webappsec.org/SSI-Injection</reference>
	<reference/>
</vuln_item_wasc_36>

<vuln_items>wasc_37</vuln_items>
<vuln_item_wasc_37>
	<alert>Fiksacja Sesji</alert>
	<desc>Fiksacja Sesji to technika ataku, która wymusza identyfikację sesji użytkownika na sprecyzowaną wartość. W zależności od funkcjonalności docelowej witryny internetowej można zastosować szereg technik w celu "zafiksowania" wartości identyfikatora sesji. Te techniki sięgają od exploitów Cross-site Scripting po zasypywanie strony z wcześniej utworzonymi żądaniami HTTP. Po ustaleniu identyfikatora sesji użytkownika osoba atakująca będzie czekać na zalogowanie się tego użytkownika. Gdy użytkownik to zrobi, atakujący wykorzystuje predefiniowane wartości identyfikatora sesji, aby przyjąć tę samą tożsamość online.

Zasadniczo istnieją dwa typy systemów zarządzania sesjami, jeśli chodzi o wartości ID. Pierwszy typ to "permisywne" systemy, które pozwalają przeglądarkom internetowym na określenie dowolnego identyfikatora. Drugi typ to "ścisłe" systemy, które akceptują tylko wartości wygenerowane przez serwer. Dzięki systemom permisywnym, arbitralne identyfikatory sesji są utrzymywane bez kontaktu z witryną internetową. Ścisłe systemy wymagają, aby atakujący utrzymywał "sesję pułapki", z okresowym kontaktem z witryną internetową, zapobiegając przekroczeniu limitu czasu bezczynności.

Bez aktywnej ochrony przed Fiksacją Sesji, atak można podłączyć do dowolnej witryny sieci Web, która używa sesji do identyfikowania uwierzytelnionych użytkowników. Strony internetowe używające identyfikatorów sesji ID są zwykle oparte na plikach cookie, ale używane są również adresy URL i ukryte pola formularzy. Niestety sesje oparte na plikach cookie są najłatwiejsze do zaatakowania. Większość obecnie zidentyfikowanych metod ataków ma na celu utrwalenie plików cookie.

W przeciwieństwie do kradzieży identyfikatorów sesji użytkowników po zalogowaniu się do witryny, Fiksacja Sesji zapewnia znacznie szersze okno możliwości. Aktywna część ataku ma miejsce, zanim użytkownik się zaloguje.</desc>
	<solution>Unieważnij istniejące identyfikatory sesji przed autoryzowaniem nowej sesji użytkownika.

W przypadku platform, takich jak ASP, które nie generują nowych wartości dla plików cookie sesji, należy użyć dodatkowego pliku cookie. W tym podejściu ustaw dodatkowy plik cookie w przeglądarce użytkownika na wartość losową i ustaw zmienną sesji na tę samą wartość. Jeśli zmienna sesji i wartość cookie nigdy się nie zgadzają, unieważnij sesję i wymuś ponownego logowanie użytkownika.</solution>
	<reference>http://projects.webappsec.org/Session-Fixation</reference>
	<reference>http://cwe.mitre.org/data/definitions/384.html</reference>
</vuln_item_wasc_37>

<vuln_items>wasc_38</vuln_items>
<vuln_item_wasc_38>
	<alert>Nadużycie Redirectorów URL</alert>
	<desc>Redirectory adresów URL reprezentują typową funkcjonalność wykorzystywaną przez strony internetowe do przekazywania przychodzących żądań do alternatywnego zasobu. Można tego dokonać z różnych powodów i często robi się to w celu umożliwienia przenoszenia zasobów w strukturze katalogów i uniknięcia łamania funkcjonalności dla użytkowników, którzy zażądają zasobu w jego poprzedniej lokalizacji. Przekierowania adresów URL można również wykorzystać do zaimplementowania równoważenia obciążenia, wykorzystania skrótów URL lub nagrywania połączeń wychodzących. Jest to ostatnia implementacja, która jest często używana w atakach phishingowych, jak opisano w poniższym przykładzie. Redirectory adresów URL niekoniecznie stanowią bezpośrednią lukę w zabezpieczeniach, ale mogą być nadużywane przez intruzów próbujących przekonać ofiary poprzez inżynierię społeczną, że odwiedzają witrynę inną niż w rzeczywistości.</desc>
	<solution>Zakładaj, że wszystkie dane wejściowe są szkodliwe. Use an "accept known good" input validation strategy, i.e., use an allow list of acceptable inputs that strictly conform to specifications. Odrzucaj wszystkie dane wejściowe, które nie są ściśle dopasowane ze specyfikacjami lub przeobraź je w takie, które są dopasowane. Do not rely exclusively on looking for malicious or malformed inputs (i.e., do not rely on a deny list). However, deny lists can be useful for detecting potential attacks or determining which inputs are so malformed that they should be rejected outright.

Kiedy przeprowadzasz weryfikację danych wejściowych, bierz pod uwagę wszystkie potencjalnie ważne właściwości, włączając długość, pełny zasięg akceptowalnych wartości, brakujących lub dodatkowych danych wejściowych, zgodność poprzez ważne pola i dostosowanie się do zasad sprawy. As an example of business rule logic, "boat" may be syntactically valid because it only contains alphanumeric characters, but it is not valid if you are expecting colors such as "red" or "blue."

Use an allow list of approved URLs or domains to be used for redirection.

Użyj strony pośredniej z komunikatem, która zapewnia użytkownikowi wyraźne ostrzeżenie, że opuszczają twoją witrynę. Wprowadź długi czas oczekiwania przed przekierowaniem lub wymuś na użytkowniku kliknięcie w łącze. Zachowaj ostrożność, aby uniknąć problemów z XSS podczas generowania strony z ostrzeżeniem.

Kiedy zbiór akceptowalnych obiektów, takich jak nazwy plików lub adresy URL, jest ograniczony lub znany, utwórz odwzorowanie ze zbioru stałych wartości wejściowych (takich jak identyfikatory numeryczne) do rzeczywistych nazw plików lub adresów URL i odrzuć wszystkie inne dane wejściowe.

Na przykład identyfikator 1 może zostać odwzorowany na "/login.asp", a identyfikator 2 może zostać odwzorowany na "http://www.example.com/". Funkcje takie jak ESAPI AccessReferenceMap dają taką możliwość.

Fazy: Architektura i Projektowanie; Implementacja
Zrozum wszystkie potencjalne obszary gdzie niezaufane dane wejściowe wejdą w twoje oprogramowanie: parametry lub argumenty, ciasteczka, jakikolwiek odczyt z sieci, zmiennych środowiskowych, wyszukiwania wstecznego DNS, wyniki zapytania, nagłówki żądań, komponenty URL, e-mail, pliki, bazy danych i dowolne zewnętrzne
systemy, które dostarczają dane do aplikacji. Pamiętaj o tym, że takie dane wejściowe mogą uzyskane poprzez wezwania API.

Wiele otwartych problemów przekierowania pojawia się, ponieważ programista założył, że pewnych danych wejściowych nie można zmodyfikować, takich jak pliki cookie i ukryte pola formularzy.</solution>
	<reference>http://projects.webappsec.org/URL-Redirector-Abuse</reference>
	<reference>http://cwe.mitre.org/data/definitions/601.html</reference>
</vuln_item_wasc_38>

<vuln_items>wasc_39</vuln_items>
<vuln_item_wasc_39>
	<alert>Wstrzyknięcie XPath</alert>
	<desc>Wstrzyknięcie XPath to technika ataku wykorzystywana do wykorzystywania aplikacji budujących zapytania XPath (język ścieżki XML) z danych wprowadzonych przez użytkownika w celu wysyłania zapytań lub nawigacji dokumentów XML. Może być użyta bezpośrednio przez aplikację do wysyłania zapytań do dokumentu XML, jako część większej operacji, takiej jak zastosowanie transformacji XSLT do dokumentu XML lub zastosowanie XQuery do dokumentu XML. Składnia XPath ma pewne podobieństwo do zapytania SQL i w rzeczywistości możliwe jest tworzenie zapytań podobnych do SQL w dokumencie XML przy użyciu XPath.

Jeśli aplikacja wykorzystuje konstrukcję zapytań XPath w czasie wykonywania, osadzając w kwerendzie niebezpieczne dane wejściowe użytkownika, możliwe jest, że osoba atakująca wprowadzi dane do zapytania w taki sposób, że nowo utworzone zapytanie zostanie przeanalizowane w sposób odmienny od zamiaru programisty.</desc>
	<solution>Używaj sparametryzowanych zapytań XPath (np. używając XQuery). Pomoże to zapewnić separację między płaszczyzną danych a płaszczyzną sterowania.

Odpowiednio sprawdzaj dane wprowadzone przez użytkownika. Odrzuć dane w stosownych przypadkach, przefiltruj je w razie potrzeby i rezygnuj w razie potrzeby. Upewnij się, że dane wejściowe, które będą używane w zapytaniach XPath, są bezpieczne w tym kontekście.</solution>
	<reference>http://projects.webappsec.org/XPath-Injection</reference>
	<reference>http://cwe.mitre.org/data/definitions/643.html</reference>
</vuln_item_wasc_39>

<vuln_items>wasc_40</vuln_items>
<vuln_item_wasc_40>
	<alert>Niewystarczające Walidacja Procesu</alert>
	<desc>Niewystarczająca Walidacja Procesu występuje, gdy aplikacja internetowa nie ogranicza atakującego przed omijaniem zamierzonego przepływu lub logiki biznesowej aplikacji. W realnym świecie niewystarczająca walidacja procesów doprowadziła do nieskutecznych kontroli dostępu i strat finansowych.

Istnieją dwa główne typy procesów, które wymagają sprawdzenia poprawności: kontrola przepływu i logika biznesowa.

"Kontrola przepływu" odnosi się do procesów wieloetapowych, które wymagają, aby każdy krok był wykonywany w określonej kolejności przez użytkownika. Gdy atakujący wykonuje krok nieprawidłowo lub niezgodnie z kolejnością, kontrola dostępu może zostać ominięta i może wystąpić błąd integralności aplikacji. Przykładami wieloetapowych procesów są przelewy, odzyskiwanie hasła, przeprowadzenie zakupu i rejestracja konta.

"Logika biznesowa" odnosi się do kontekstu, w którym proces będzie wykonywany zgodnie z wymogami biznesowymi. Wykorzystanie słabości logiki biznesowej wymaga znajomości biznesu; jeśli nie jest potrzebna wiedza, aby ją wykorzystać, najprawdopodobniej nie jest to błąd logiki biznesowej. Z tego powodu typowe środki bezpieczeństwa, takie jak skanowanie i weryfikacja kodu, nie znajdą tej klasy słabości. Jedno z podejść do testowania oferuje OWASP w swoim Przewodniku Testowania.</desc>
	<solution>TBA</solution>
	<reference>http://projects.webappsec.org/Insufficient-Process-Validation</reference>
	<reference/>
</vuln_item_wasc_40>

<vuln_items>wasc_41</vuln_items>
<vuln_item_wasc_41>
	<alert>Rozdęcie Atrybutu XML</alert>
	<desc>Rozdęcie Atrybutu XML to atak typu "odmowa usługi" skierowany na parsery XML. Atakujący dostarcza złośliwy dokument XML, który jest przetwarzany przez podatne na błędy analizatory składni XML w bardzo nieefektywny sposób, co prowadzi do nadmiernego obciążenia procesora. Istotą ataku jest umieszczenie wielu atrybutów w tym samym węźle XML. Vulnerable XML parsers manage the attributes in an inefficient manner (e.g. in a data container for which insertion of a new attribute has O(n) runtime), resulting in a non-linear (in this example, quadratic, i.e. O(n2)) overall runtime, leading to a denial of service condition via CPU exhaustion.</desc>
	<solution>Zaprojektuj w architekturze systemu mechanizmy dławiące. Najlepszą ochroną jest ograniczenie liczby materiałów, które nieupoważniony użytkownik może zużyć. Silny wzorzec uwierzytelniania i kontroli dostępu zapobiegnie takim atakom w pierwszej kolejności. Aplikacja logowania powinna być chroniona przed atakami DoS tak bardzo, jak to możliwe. Ograniczenie dostępu do bazy danych, być może poprzez buforowanie zestawów wyników, może pomóc zminimalizować eksploatowanie zasobów. Aby jeszcze bardziej ograniczyć możliwość ataku DoS, należy rozważyć śledzenie liczby żądań otrzymanych od użytkowników i blokowanie żądań przekraczających zdefiniowany próg częstotliwości.

Ograniczanie ataków polegających na wyczerpaniu zasobów wymaga, aby system docelowy:
  * rozpoznawał atak i odmawia temu użytkownikowi dalszego dostępu przez określony czas, lub
  * równomiernie ograniczał wszystkie żądania, aby utrudnić korzystanie z zasobów szybciej, niż można je ponownie uwolnić. 

Pierwsze z tych rozwiązań jest jednak problemem samym w sobie, ponieważ może pozwolić atakującym na uniemożliwienie korzystania z systemu przez określonego, ważnego użytkownika. Jeśli atakujący podszywa się pod prawomocnego użytkownika, może uniemożliwić mu dostęp do danego serwera.

Drugie rozwiązanie jest po prostu trudne do efektywnego wdrożenia - a nawet jeśli jest właściwie wykonane, nie zapewnia pełnego rozwiązania. Zwyczajnie sprawia, że ​​atak wymaga więcej środków ze strony atakującego.

Upewnij się, że protokoły mają określone ograniczenia w skali plasowanej na nich.

Upewnij się, że wszystkie awarie w alokacji zasobów stawiają system w bezpiecznej pozycji.</solution>
	<reference>http://projects.webappsec.org/XML-Attribute-Blowup</reference>
	<reference>http://cwe.mitre.org/data/definitions/400.html</reference>
</vuln_item_wasc_41>

<vuln_items>wasc_42</vuln_items>
<vuln_item_wasc_42>
	<alert>Nadużycie Funkcjonalności</alert>
	<desc>Nadużycie Funkcjonalności jest techniką ataku, która wykorzystuje własne funkcje i funkcjonalność strony internetowej do ataku na siebie lub innych. Nadużycie Funkcjonalności można opisać jako nadużycie zamierzonej funkcjonalności aplikacji w celu wykonania niepożądanego wyniku. Ataki te mają zróżnicowane wyniki, takie jak zużywanie zasobów, omijanie kontroli dostępu lub wyciek informacji. Potencjał i poziom nadużyć może się różnić w zależności od strony internetowej oraz aplikacji. Ataki Nadużycia Funkcjonalność są często kombinacją innych typów ataków i/lub wykorzystują inne wektory ataku.</desc>
	<solution>Zawsze korzystaj z interfejsów API w określony sposób.</solution>
	<reference>http://projects.webappsec.org/Abuse-of-Functionality</reference>
	<reference>http://cwe.mitre.org/data/definitions/227.html</reference>
</vuln_item_wasc_42>

<vuln_items>wasc_43</vuln_items>
<vuln_item_wasc_43>
	<alert>Zewnętrzne Odwołania XML</alert>
	<desc>Ta technika wykorzystuje funkcję XML do dynamicznego budowania dokumentów w czasie przetwarzania. Komunikat XML może jawnie dostarczać dane lub wskazywać URI, w którym dane istnieją. W technice tego ataku podmioty zewnętrzne mogą zastąpić wartość jednostki złośliwymi danymi, alternatywnymi poleceniami lub mogą zagrozić bezpieczeństwu danych, do których dostęp ma aplikacja serwer/XML.
	Atakujący mogą również używać Zewnętrznych Odwołań, aby serwer usług WWW pobierał złośliwy kod lub zawartość na serwer w celu użycia w atakach wtórnych lub następczych.</desc>
	<solution>TBA</solution>
	<reference>http://projects.webappsec.org/XML-External-Entities</reference>
	<reference/>
</vuln_item_wasc_43>

<vuln_items>wasc_44</vuln_items>
<vuln_item_wasc_44>
	<alert>Ekspansja Makr XML</alert>
	<desc>Atak polegający na ekspansji makr XML, wykorzystuje możliwości w DTD XML, które umożliwiają tworzenie niestandardowych makr, zwanych obiektami, które mogą być używane w całym dokumencie. Rekursywnie definiując zestaw niestandardowych elementów makr na początku dokumentu, atakujący może przeciążyć parsery, które próbują całkowicie rozwiązać encje, zmuszając je do iteracji niemal w nieskończoność tych rekurencyjnych definicji.

Szkodliwy komunikat XML jest używany do wymuszenia rozszerzenia jednostki rekurencyjnej (lub innego powtórnego przetwarzania), które całkowicie wykorzystuje dostępne zasoby serwera.</desc>
	<solution>Jeśli to możliwe, zabraniaj używania definicji DTD lub użyj parsera XML, który ogranicza ekspansję rekurencyjnych obiektów DTD.

Przed rozpoczęciem analizowania plików XML z powiązanymi definicjami DTD należy przeskanować deklaracje encji rekurencyjnych i nie kontynuować analizowania zawartości potencjalnie "wybuchowej".</solution>
	<reference>http://projects.webappsec.org/XML-Entity-Expansion</reference>
	<reference>http://cwe.mitre.org/data/definitions/776.html</reference>
</vuln_item_wasc_44>

<vuln_items>wasc_45</vuln_items>
<vuln_item_wasc_45>
	<alert>Zbieranie Śladów</alert>
	<desc>Najpowszechniejszą metodologią dla atakujących jest najpierw zbadanie obecności celu w sieci i zebranie jak największej ilości informacji. Dzięki tym informacjom osoba atakująca może opracować dokładny scenariusz ataku, który skutecznie wykorzysta lukę w typie/wersji oprogramowania wykorzystywanej przez hosta docelowego.

Wielopoziomowy "odcisk palca" jest podobny do jego poprzednika, zbierania "odcisków palców" TCP/IP (skanerem takim jak Nmap), z tym że koncentruje się on na warstwie aplikacji modelu OSI zamiast warstwy transportowej. Teoria stojąca za zbieraniem "odcisków palców" polega na stworzeniu dokładnego profilu platformy celu, technologii oprogramowania aplikacji internetowej, bazy danych backend, konfiguracji i ewentualnie również architektury/topologii sieci.</desc>
	<solution>TBA</solution>
	<reference>http://projects.webappsec.org/Fingerprinting</reference>
	<reference/>
</vuln_item_wasc_45>

<vuln_items>wasc_46</vuln_items>
<vuln_item_wasc_46>
	<alert>Wstrzykiwanie XQuery</alert>
	<desc>Wstrzykiwanie XQuery to wariant klasycznego ataku typu SQL injection na język XML XQuery. Wstrzykiwanie XQuery wykorzystuje nieprawidłowo sprawdzone dane, które są przekazywane do komend XQuery. To z kolei wykona polecenia w imieniu atakującego, do których mają dostęp procedury XQuery. Wstrzyknięcie XQuery może być używane do wyliczania elementów w środowisku ofiary, wprowadzania poleceń do lokalnego hosta lub wykonywania zapytań do zdalnych plików i źródeł danych. Podobnie jak ataki typu SQL injection, atakujący przechodzi przez punkt wejścia aplikacji, aby dotrzeć do warstwy dostępu do zasobów.</desc>
	<solution>Użyj sparametryzowanych zapytań. Pomoże to zapewnić separację między płaszczyzną danych a płaszczyzną sterowania.

Odpowiednio sprawdzaj dane wprowadzone przez użytkownika. Odrzuć dane w stosownych przypadkach, przefiltruj je w razie potrzeby i rezygnuj w razie potrzeby. Upewnij się, że dane wejściowe, które będą używane w zapytaniach XQL, są bezpieczne w tym kontekście.</solution>
	<reference>http://projects.webappsec.org/XQuery-Injection</reference>
	<reference>http://cwe.mitre.org/data/definitions/652.html</reference>
</vuln_item_wasc_46>

<vuln_items>wasc_47</vuln_items>
<vuln_item_wasc_47>
	<alert>Niewystarczające Wygaszenie Sesji</alert>
	<desc>Niewystarczające Wygaśnięcie Sesji ma miejsce, gdy aplikacja internetowa zezwala osobie atakującej na ponowne użycie starych poświadczeń sesji lub identyfikatorów sesji w celu autoryzacji. Niewystarczające Wygaśnięcie Sesji zwiększa narażenie witryny sieci Web na ataki kradnące lub ponownie wykorzystujące identyfikatory sesji użytkownika.

Ponieważ protokół HTTP jest protokołem bezstanowym, witryny sieci Web często używają plików cookie do przechowywania identyfikatorów sesji, które jednoznacznie identyfikują użytkowników pomiędzy żądaniami. W związku z tym należy zachować poufność każdego identyfikatora sesji, aby uniemożliwić wielu użytkownikom dostęp do tego samego konta. Skradziony identyfikator sesji może być używany do przeglądania konta innego użytkownika lub dokonywania nieuczciwej transakcji.

Wygaśnięcie sesji składa się z dwóch typów limitu czasu: bezczynności i bezwzględnego. Limit czasu bezwzględnego jest definiowany przez całkowity czas, przez jaki sesja może być ważna bez ponownego uwierzytelnienia, a limit czasu bezczynności to czas bezczynności dozwolony przed unieważnieniem sesji. Brak właściwego wygaśnięcia sesji może zwiększyć prawdopodobieństwo powodzenia niektórych ataków. Długi okres ważności zwiększa szansę atakującego na odgadnięcie prawidłowego identyfikatora sesji. Im dłuższy czas wygaśnięcia, tym więcej współbieżnych sesji otwartych będzie w danym momencie. Im większa pula sesji, tym bardziej prawdopodobne będzie, że osoba atakująca będzie mogła odgadnąć ID przypadkowo. Chociaż krótki czas nieaktywności sesji nie pomaga jeśli token jest natychmiast użyty, krótki czas wygaśnięcia pomaga zapewnić, że token jest trudniejszy do przechwycenia, dopóki jest nadal ważny.

Aplikacja internetowa powinna unieważnić sesję po upływie zdefiniowanego czasu bezczynności (limit czasu) i zapewnić użytkownikowi środki do unieważnienia własnej sesji, tj. wylogowania; pomaga to utrzymać trwałość identyfikatora sesji tak krótko, jak to tylko możliwe i jest konieczne we współdzielonym środowisku komputerowym, w którym więcej niż jedna osoba ma nieograniczony fizyczny dostęp do komputera. Funkcja wylogowania powinna być widoczna dla użytkownika, jawnie unieważniać sesję użytkownika i uniemożliwiać ponowne użycie tokena sesji.</desc>
	<solution>Ustaw datę wygaśnięcia sesji / danych logowania.</solution>
	<reference>http://projects.webappsec.org/Insufficient-Session-Expiration</reference>
	<reference>http://cwe.mitre.org/data/definitions/613.html</reference>
</vuln_item_wasc_47>

<vuln_items>wasc_48</vuln_items>
<vuln_item_wasc_48>
	<alert>Niezabezpieczone Indeksowanie</alert>
	<desc>Niezabezpieczone Indeksowanie stanowi zagrożenie dla poufności danych na stronie internetowej. Indeksowanie zawartości strony internetowej za pośrednictwem procesu, który ma dostęp do plików, które nie powinny być publicznie dostępne, może potencjalnie ujawnić informacje o istnieniu takich plików i ich zawartości. W procesie indeksowania takie informacje są gromadzone i przechowywane w procesie indeksowania, który później może zostać odtworzony (choć nie trywialnie) przez określonego agresora, zazwyczaj za pomocą szeregu zapytań do wyszukiwarki. Atakujący nie omija modelu zabezpieczeń wyszukiwarki. W związku z tym atak ten jest subtelny i bardzo trudny do wykrycia i zablokowania - nie jest łatwo odróżnić zapytania atakującego od prawidłowych zapytań użytkownika.</desc>
	<solution>TBA</solution>
	<reference>http://projects.webappsec.org/Insecure-Indexing</reference>
	<reference/>
</vuln_item_wasc_48>

<vuln_items>wasc_49</vuln_items>
<vuln_item_wasc_49>
	<alert>Niewłaściwe Odzyskiwanie Hasła</alert>
	<desc>Nieprawidłowe Odzyskiwanie Haseł to sytuacja, w której strona internetowa pozwala osobie atakującej nielegalnie uzyskać, zmienić lub odzyskać hasło innego użytkownika. Konwencjonalne metody uwierzytelniania witryn internetowych wymagają od użytkowników wybrania i zapamiętania hasła. Użytkownik powinien być jedyną osobą, która zna hasło i musi być dokładnie zapamiętana. W miarę upływu czasu zdolność użytkownika do zapamiętywania hasła zanika. Sprawa jest jeszcze bardziej skomplikowana, gdy przeciętny użytkownik odwiedza 20 witryn wymagających podania hasła.  (Badanie RSA: http://news.bbc.co.uk/1/hi/technology/3639679.stm) Dlatego odzyskiwanie haseł jest ważną częścią obsługi użytkowników online.

Przykłady zautomatyzowanych procesów odzyskiwania hasła obejmują wymaganie od użytkownika odpowiedzi na "tajne pytanie" zdefiniowane jako część procesu rejestracji użytkownika. To pytanie może zostać wybrane z listy pytań lub wskazane przez użytkownika. Innym wykorzystywanym mechanizmem jest zapewnienie użytkownikowi "podpowiedzi" podczas rejestracji, która pomoże użytkownikowi zapamiętać jego hasło. Other mechanisms require the user to provide several pieces of personal data such as their social security number, home address, zip code etc. to validate their identity. Gdy użytkownik udowodni, kim jest, system odzyskiwania wyświetli lub wyśle mu nowe hasło.

Uważa się, że strona internetowa na Niezabezpieczone Odzyskiwanie Hasła, gdy atakujący jest w stanie udaremnić użycie mechanizmu odzyskiwania. Dzieje się tak, gdy informacje wymagane do sprawdzenia tożsamości użytkownika do odzyskania można łatwo odgadnąć lub obejść. Systemy odzyskiwania haseł mogą zostać naruszone poprzez użycie ataków typu 'brute force', wewnętrzne słabości systemu lub prostych, odgadywanych tajnych pytań.</desc>
	<solution>Upewnij się, że wszystkie dane wejściowe dostarczone przez użytkownika do mechanizmu odzyskiwania haseł są dokładnie filtrowane i sprawdzane.

Nie używaj standardowych słabych pytań bezpieczeństwa i używaj kilku pytań bezpieczeństwa.

Upewnij się, że występuje ograniczenie liczby nieprawidłowych odpowiedzi na pytanie bezpieczeństwa. Wyłącz funkcję odzyskiwania haseł po określonej (małej) liczbie nieprawidłowych domysłów.

Wymagaj, aby użytkownik poprawnie odpowiedział na pytanie bezpieczeństwa przed zresetowaniem hasła i wysłaniem nowego hasła na zarejestrowany adres e-mail.

Nigdy nie pozwól użytkownikowi kontrolować, jaki adres e-mail będzie wysyłał nowe hasło w mechanizmie odzyskiwania hasła.

Przypisz nowe tymczasowe hasło zamiast ujawniać oryginalne hasło.</solution>
	<reference>http://projects.webappsec.org/Insufficient-Password-Recovery</reference>
	<reference>http://cwe.mitre.org/data/definitions/640.html</reference>
</vuln_item_wasc_49>

</vulnerabilities>
